Subject: Re: [Status] [status] Question on MPLS OAM presentation
From: Gregory Mirsky <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Tue, 30 Jul 2013 15:08:04 +0000
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <status.ietf.org>

Hi Ruediger, Nobo, et al.,
I'll offer my view, tagged by GIM>>, on Q2 and snip the rest. 

	Regards,
		Greg

[...]

Q2: is this an SR issue or a general MPLS issue? I.e. if there are two IFs between LDP based routers of the same metric and ECMP enabled, would MPLS OAM detect a misrouted packet? If yes, then an adaptation to SR should be possible. If no, MPLS OAM needs to be updated.

GIM>> If ECMP in SR assumes use of EL, then MPLS OAM would not have problem to be in-band to payload. In such case we'll have MEG per EL, even if MEG is implicit. Said that I agree that we need to move to describing how MPLS-TP OAM applies to MPLS networks. There we can have SR as use case study among other scenarios.

[...]

-----Original Message-----
From: Nobo Akiya (nobo) [mailto:[email-masked]]
Sent: Tuesday, July 30, 2013 2:50 PM
To: Geib, Rüdiger
Cc: [email-masked]
Subject: [status] Question on MPLS OAM presentation

Hello Ruediger,

http://www.ietf.org/proceedings/87/slides/slides-87-status-1.pdf

I read your slides, very interesting technique. I have couple of observations around how proposal applies to Adj-SID and a general question.

O-1: There seems to be a restriction on labels which can be imposed. For example, if you have Adj-SID followed by Node-SID somewhere in imposed label stack, then mis-forwarding of Adj-SID will not be detected as nexthop (whichever it may be) will forward based on next Node-SID at that point. Packet will most likely happily "resume" the traversal.

O-2: In a scenario where imposed label stack is all Adj-SIDs, proposal provides high probability of validation on hop basis, but not at interface basis. If there are parallel links between a pair of nodes, and if Adj-SID results in forwarding on wrong interface but still reaching intended nexthop, then this doesn't appear to be detectable.

Q-1: What is the "data" following the label stack? In particular, is it IP encapsulated?

Regards,
Nobo

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

From: <[email-masked]>
To: <[email-masked]>
Date: Tue, 30 Jul 2013 17:06:59 +0200
Accept-Language: en-US, de-DE
acceptlanguage: en-US, de-DE
Cc: [email-masked]
Subject: Re: [Status] [status] Question on MPLS OAM presentation - add on

Hello Nobo,

[snip]

The solution I scetched in my slides works in an ECMP enabled environment. The aim is to supervise all possible LSPs. The IP-address follows MPLS-OAM mechanisms to execute a particular path between two LERs. We'd first detect the executed path using MPLS OAM (using downstream mapping TLV, I think). Thus we determine a particular IP-address to execute the LSP we wish to monitor. Then we ping along that path.

Regards,

Ruediger

> Q3: the data in DTs system is IP framed. This is required to switch between
> IP paths. if the Entropy Label is applied to execute ECMP paths or bundled
> links, then the data format doesn't matter. IP stacks are of course supported
> by many end systems and software to administrate and evaluate IP packets
> is easily available.

I see. What is the destination IP address used in the proposal?

Regards,
Nobo

> -----Original Message-----
> From: Gregory Mirsky [mailto:[email-masked]]
> Sent: Tuesday, July 30, 2013 10:21 AM
> To: [email-masked]; Nobo Akiya (nobo)
> Cc: [email-masked]
> Subject: RE: [status] Question on MPLS OAM presentation - add on
>
> Hi Ruediger,
> What unites all flavours of MPLS (Topology Driven MPLS, a.k.a. IP(LDP)/MPLS,
> MPLS-TE, and MPLS-TP) is common data plane even though control plane
> might be different or absent all together (MPLS-TP). And since MPLS OAM is
> function of MPLS data plane it is equally applicable to MPLS network
> regardless of what its control plane is (almost as you should not use IP
> encapsulation in MPLS-TP network that doesn't use IP addressing).
> If data plane of SR is MPLS, then, IMHO, MPLS OAM must be applicable to SR.
>
>       Regards,
>               Greg
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Tuesday, July 30, 2013 4:11 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Status] [status] Question on MPLS OAM presentation - add on
>
> Hello Nobo,
>
> Regards,
>
> I just see, if MPLS OAM should be felt to be inappropriate, then call it SR
> OAM. Just for the case that someone points out that there's no more MPLS
> control plane (signaling). Label cross connect tables and ECMP will be
> present and MPLS OAM functions shouldn't be depricated.
>
> Ruediger
>
>
> -----Original Message-----
> From: Nobo Akiya (nobo) [mailto:[email-masked]]
> Sent: Tuesday, July 30, 2013 2:50 PM
> To: Geib, Rüdiger
> Cc: [email-masked]
> Subject: [status] Question on MPLS OAM presentation
>
> Hello Ruediger,
>
> http://www.ietf.org/proceedings/87/slides/slides-87-status-1.pdf
>
> I read your slides, very interesting technique. I have couple of observations
> around how proposal applies to Adj-SID and a general question.
>
> O-1: There seems to be a restriction on labels which can be imposed. For
> example, if you have Adj-SID followed by Node-SID somewhere in imposed
> label stack, then mis-forwarding of Adj-SID will not be detected as nexthop
> (whichever it may be) will forward based on next Node-SID at that point.
> Packet will most likely happily "resume" the traversal.
>
> O-2: In a scenario where imposed label stack is all Adj-SIDs, proposal
> provides high probability of validation on hop basis, but not at interface
> basis. If there are parallel links between a pair of nodes, and if Adj-SID
> results in forwarding on wrong interface but still reaching intended nexthop,
> then this doesn't appear to be detectable.
>
> Q-1: What is the "data" following the label stack? In particular, is it IP
> encapsulated?
>
> Regards,
> Nobo
>
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: "Nobo Akiya (nobo)" <[email-masked]>
To: Gregory Mirsky <[email-masked]>, "[email-masked]" <[email-masked]>
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] [status] Question on MPLS OAM presentation - add on

Hello Ruediger, Greg,

I see the proposal to bring interesting addition/element to MPLS OAM in SR. With that said, I agree with Greg that there's value in adapting existing MPLS OAM suites (LSP ping/trace, Seamless BFD, etc) for SR.

> Q1: you are in SR solution space, while my presentation is oriented at DTs
> implementation (based on available protocols). I didn't yet consider all
> possibilities of SR and Adjacency Labels are a challenge (to me). I'd
> spontaneously suggest an adapted MPLS OAM to tackle Q1.

Agree.

> After execution
> of the adjacency segment, the misconfiguration would be detectable then,
> if the last hop MPLS trace echo response indicates how the adjacency label
> was intended to be used.

This can be detected with "receive info" returned from a hop after Adj-SID. With LSP ping, DSMAP/DDMAP  "I" flag set can do this, as well as MPLS label verification aspect of Seamless BFD.

> Q2: is this an SR issue or a general MPLS issue? I.e. if there are two IFs
> between LDP based routers of the same metric and ECMP enabled, would
> MPLS OAM detect a misrouted packet? If yes, then an adaptation to SR
> should be possible. If no, MPLS OAM needs to be updated.

Yes it is a general MPLS issue, and IMO definition of Adj-SID (strict forwarding) generates desire for this to be detected, if forwarding goes beyond strict boundary.

> Q3: the data in DTs system is IP framed. This is required to switch between
> IP paths. if the Entropy Label is applied to execute ECMP paths or bundled
> links, then the data format doesn't matter. IP stacks are of course supported
> by many end systems and software to administrate and evaluate IP packets
> is easily available.

I see. What is the destination IP address used in the proposal?

Regards,
Nobo

> -----Original Message-----
> From: Gregory Mirsky [mailto:[email-masked]]
> Sent: Tuesday, July 30, 2013 10:21 AM
> To: [email-masked]; Nobo Akiya (nobo)
> Cc: [email-masked]
> Subject: RE: [status] Question on MPLS OAM presentation - add on
> 
> Hi Ruediger,
> What unites all flavours of MPLS (Topology Driven MPLS, a.k.a. IP(LDP)/MPLS,
> MPLS-TE, and MPLS-TP) is common data plane even though control plane
> might be different or absent all together (MPLS-TP). And since MPLS OAM is
> function of MPLS data plane it is equally applicable to MPLS network
> regardless of what its control plane is (almost as you should not use IP
> encapsulation in MPLS-TP network that doesn't use IP addressing).
> If data plane of SR is MPLS, then, IMHO, MPLS OAM must be applicable to SR.
> 
> 	Regards,
> 		Greg
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Tuesday, July 30, 2013 4:11 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Status] [status] Question on MPLS OAM presentation - add on
> 
> Hello Nobo,
> 
> Regards,
> 
> I just see, if MPLS OAM should be felt to be inappropriate, then call it SR
> OAM. Just for the case that someone points out that there's no more MPLS
> control plane (signaling). Label cross connect tables and ECMP will be
> present and MPLS OAM functions shouldn't be depricated.
> 
> Ruediger
> 
> 
> -----Original Message-----
> From: Nobo Akiya (nobo) [mailto:[email-masked]]
> Sent: Tuesday, July 30, 2013 2:50 PM
> To: Geib, Rüdiger
> Cc: [email-masked]
> Subject: [status] Question on MPLS OAM presentation
> 
> Hello Ruediger,
> 
> http://www.ietf.org/proceedings/87/slides/slides-87-status-1.pdf
> 
> I read your slides, very interesting technique. I have couple of observations
> around how proposal applies to Adj-SID and a general question.
> 
> O-1: There seems to be a restriction on labels which can be imposed. For
> example, if you have Adj-SID followed by Node-SID somewhere in imposed
> label stack, then mis-forwarding of Adj-SID will not be detected as nexthop
> (whichever it may be) will forward based on next Node-SID at that point.
> Packet will most likely happily "resume" the traversal.
> 
> O-2: In a scenario where imposed label stack is all Adj-SIDs, proposal
> provides high probability of validation on hop basis, but not at interface
> basis. If there are parallel links between a pair of nodes, and if Adj-SID
> results in forwarding on wrong interface but still reaching intended nexthop,
> then this doesn't appear to be detectable.
> 
> Q-1: What is the "data" following the label stack? In particular, is it IP
> encapsulated?
> 
> Regards,
> Nobo
> 
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: Gregory Mirsky <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 30 Jul 2013 14:21:26 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] [status] Question on MPLS OAM presentation - add on

Hi Ruediger,
What unites all flavours of MPLS (Topology Driven MPLS, a.k.a. IP(LDP)/MPLS, MPLS-TE, and MPLS-TP) is common data plane even though control plane might be different or absent all together (MPLS-TP). And since MPLS OAM is function of MPLS data plane it is equally applicable to MPLS network regardless of what its control plane is (almost as you should not use IP encapsulation in MPLS-TP network that doesn't use IP addressing). 
If data plane of SR is MPLS, then, IMHO, MPLS OAM must be applicable to SR.

	Regards,
		Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, July 30, 2013 4:11 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Status] [status] Question on MPLS OAM presentation - add on

Hello Nobo,

Regards,

I just see, if MPLS OAM should be felt to be inappropriate, then call it SR OAM. Just for the case that someone points out that there's no more MPLS control plane (signaling). Label cross connect tables and ECMP will be present and MPLS OAM functions shouldn't be depricated.

Ruediger

-----Original Message-----
From: Nobo Akiya (nobo) [mailto:[email-masked]]
Sent: Tuesday, July 30, 2013 2:50 PM
To: Geib, Rüdiger
Cc: [email-masked]
Subject: [status] Question on MPLS OAM presentation

Hello Ruediger,

http://www.ietf.org/proceedings/87/slides/slides-87-status-1.pdf

I read your slides, very interesting technique. I have couple of observations around how proposal applies to Adj-SID and a general question.

O-1: There seems to be a restriction on labels which can be imposed. For example, if you have Adj-SID followed by Node-SID somewhere in imposed label stack, then mis-forwarding of Adj-SID will not be detected as nexthop (whichever it may be) will forward based on next Node-SID at that point. Packet will most likely happily "resume" the traversal.

O-2: In a scenario where imposed label stack is all Adj-SIDs, proposal provides high probability of validation on hop basis, but not at interface basis. If there are parallel links between a pair of nodes, and if Adj-SID results in forwarding on wrong interface but still reaching intended nexthop, then this doesn't appear to be detectable.

Q-1: What is the "data" following the label stack? In particular, is it IP encapsulated?

Regards,
Nobo

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

From: <[email-masked]>
To: <[email-masked]>
Date: Tue, 30 Jul 2013 16:10:57 +0200
Accept-Language: en-US, de-DE
acceptlanguage: en-US, de-DE
Cc: [email-masked]
Subject: Re: [Status] [status] Question on MPLS OAM presentation - add on

Hello Nobo,

Regards,

I just see, if MPLS OAM should be felt to be inappropriate, then call it SR OAM. Just for the case that someone points out that there's no more MPLS control plane (signaling). Label cross connect tables and ECMP will be present and MPLS OAM functions shouldn't be depricated.

Ruediger

-----Original Message-----
From: Nobo Akiya (nobo) [mailto:[email-masked]]
Sent: Tuesday, July 30, 2013 2:50 PM
To: Geib, Rüdiger
Cc: [email-masked]
Subject: [status] Question on MPLS OAM presentation

Hello Ruediger,

http://www.ietf.org/proceedings/87/slides/slides-87-status-1.pdf

I read your slides, very interesting technique. I have couple of observations around how proposal applies to Adj-SID and a general question.

O-1: There seems to be a restriction on labels which can be imposed. For example, if you have Adj-SID followed by Node-SID somewhere in imposed label stack, then mis-forwarding of Adj-SID will not be detected as nexthop (whichever it may be) will forward based on next Node-SID at that point. Packet will most likely happily "resume" the traversal.

O-2: In a scenario where imposed label stack is all Adj-SIDs, proposal provides high probability of validation on hop basis, but not at interface basis. If there are parallel links between a pair of nodes, and if Adj-SID results in forwarding on wrong interface but still reaching intended nexthop, then this doesn't appear to be detectable.

Q-1: What is the "data" following the label stack? In particular, is it IP encapsulated?

Regards,
Nobo

From: <[email-masked]>
To: <[email-masked]>
Date: Tue, 30 Jul 2013 16:04:32 +0200
Accept-Language: en-US, de-DE
acceptlanguage: en-US, de-DE
Cc: [email-masked]
Subject: Re: [Status] [status] Question on MPLS OAM presentation

Hello Nobo,

my replies in order of your questions:

Q1: you are in SR solution space, while my presentation is oriented at DTs implementation (based on available protocols). I didn't yet consider all possibilities of SR and Adjacency Labels are a challenge (to me). I'd spontaneously suggest an adapted MPLS OAM to tackle Q1. After execution of the adjacency segment, the misconfiguration would be detectable then, if the last hop MPLS trace echo response indicates how the adjacency label was intended to be used.

Q2: is this an SR issue or a general MPLS issue? I.e. if there are two IFs between LDP based routers of the same metric and ECMP enabled, would MPLS OAM detect a misrouted packet? If yes, then an adaptation to SR should be possible. If no, MPLS OAM needs to be updated.

Q3: the data in DTs system is IP framed. This is required to switch between IP paths. if the Entropy Label is applied to execute ECMP paths or bundled links, then the data format doesn't matter. IP stacks are of course supported by many end systems and software to administrate and evaluate IP packets is easily available.

These ared speedy replies. Last time I've read the MPLS OAM spec is long ago. Sorry if I missed any of your points entirely.

Regards,

Ruediger

-----Original Message-----
From: Nobo Akiya (nobo) [mailto:[email-masked]]
Sent: Tuesday, July 30, 2013 2:50 PM
To: Geib, Rüdiger
Cc: [email-masked]
Subject: [status] Question on MPLS OAM presentation

Hello Ruediger,

http://www.ietf.org/proceedings/87/slides/slides-87-status-1.pdf

I read your slides, very interesting technique. I have couple of observations around how proposal applies to Adj-SID and a general question.

O-1: There seems to be a restriction on labels which can be imposed. For example, if you have Adj-SID followed by Node-SID somewhere in imposed label stack, then mis-forwarding of Adj-SID will not be detected as nexthop (whichever it may be) will forward based on next Node-SID at that point. Packet will most likely happily "resume" the traversal.

O-2: In a scenario where imposed label stack is all Adj-SIDs, proposal provides high probability of validation on hop basis, but not at interface basis. If there are parallel links between a pair of nodes, and if Adj-SID results in forwarding on wrong interface but still reaching intended nexthop, then this doesn't appear to be detectable.

Q-1: What is the "data" following the label stack? In particular, is it IP encapsulated?

Regards,
Nobo

From: "Nobo Akiya (nobo)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 30 Jul 2013 12:50:00 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: [Status] [status] Question on MPLS OAM presentation

Hello Ruediger,

http://www.ietf.org/proceedings/87/slides/slides-87-status-1.pdf

I read your slides, very interesting technique. I have couple of observations around how proposal applies to Adj-SID and a general question.

O-1: There seems to be a restriction on labels which can be imposed. For example, if you have Adj-SID followed by Node-SID somewhere in imposed label stack, then mis-forwarding of Adj-SID will not be detected as nexthop (whichever it may be) will forward based on next Node-SID at that point. Packet will most likely happily "resume" the traversal.

O-2: In a scenario where imposed label stack is all Adj-SIDs, proposal provides high probability of validation on hop basis, but not at interface basis. If there are parallel links between a pair of nodes, and if Adj-SID results in forwarding on wrong interface but still reaching intended nexthop, then this doesn't appear to be detectable.

Q-1: What is the "data" following the label stack? In particular, is it IP encapsulated?

Regards,
Nobo

From: <[email-masked]>
To: <[email-masked]>
Date: Tue, 30 Jul 2013 14:33:57 +0200
Accept-Language: en-US, de-DE
acceptlanguage: en-US, de-DE
Cc: [email-masked]
Subject: Re: [Status] ??: Comments on draft-filsfils-rtgwg-segment-routing (Entropy labels for segment routing)

Sender: [email-masked]
From: Sriganesh Kini <[email-masked]>
Date: Tue, 30 Jul 2013 04:56:44 -0700
To: "Henderickx, Wim (Wim)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Loa Andersson <[email-masked]>
Subject: Re: [Status] =?utf-8?b?562U5aSNOiBDb21tZW50cyBvbiBkcmFmdC1maWxzZmls?= =?utf-8?q?s-rtgwg-segment-routing_(Entropy_labels_for_segment_ro?= =?utf-8?q?uting)?X-BeenThere: [email-masked]

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

Loa,

Another scenario is where the Node-SIDs are used in the stack. To reach the
node if ECMP is required then EL is required.

- Sri

On Tue, Jul 30, 2013 at 2:30 AM, Henderickx, Wim (Wim) <
[email-masked]> wrote:

> A concept of ADJ-SID-sets are defined which is a identifier/label on a
> number of interfaces of a node. When the packet uses a label from the
> ADJ-SID-set stack the packet is subject to hashing. In this scenario the
> entropy label might be used.
>
> For regular ADJ-SID tight to a given interface it is not required since
> the ingress node will do the hashing with full packet header.
>
> On 30/07/13 11:23, "Loa Andersson" <[email-masked]> wrote:
>
> >Xiaohu and Sri,
> >
> >I'm struggling to understand why entropy labels would ever occur in
> >a source routed label stack, load sharing would be be done as part of
> >creating the source routed routes.
> >
> >/Loa
> >
> >On 2013-07-30 10:40, Xuxiaohu wrote:
> >> Totally  agree.  In addition, some extension to ISIS and OSPF may also
> >> be needed for advertising the ELC.
> >>
> >> Best regards,
> >>
> >> Xiaohu
> >>
> >> ------------------------------------------------------------------------
> >> *å‘ä»¶äºº:* [email-masked] [[email-masked]] ä»£è¡¨
> >> Sriganesh Kini [[email-masked]]
> >> *å‘é€æ—¶é—´:* 2013å¹´7æœˆ30æ—¥ 16:12
> >> *åˆ°:* [email-masked]
> >> *ä¸»é¢˜:* [Status] Comments on draft-filsfils-rtgwg-segment-routing
> >> (Entropy labels for segment routing)
> >>
> >> Hello Clarence and other authors,
> >>
> >> Current architecture does not address the issue of entropy labels. It
> >> should be listed as an open issue.
> >>
> >> At the mic yesterday, Kireeti and others brought up this issue and the
> >> related issue of label stack getting deeper. I think this is a valid
> >> concern.
> >>
> >> An EL for the entire stack is one approach. Another could be an EL per
> >> segment. Both have their advantages and disadvantages. This issue needs
> >> to be addressed.
> >>
> >> - Sri
> >>
> >>
> >> _______________________________________________
> >> 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
>

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

<div dir="ltr">Loa,<div><br></div><div>Another scenario is where the Node-SIDs are used in the stack. To reach the node if ECMP is required then EL is required.</div><div><br></div><div>- Sri</div><div class="gmail_extra">

<br><br><div class="gmail_quote">On Tue, Jul 30, 2013 at 2:30 AM, Henderickx, Wim (Wim) <span dir="ltr">&lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A concept of ADJ-SID-sets are defined which is a identifier/label on a<br>
number of interfaces of a node. When the packet uses a label from the<br>
ADJ-SID-set stack the packet is subject to hashing. In this scenario the<br>
entropy label might be used.<br>
<br>
For regular ADJ-SID tight to a given interface it is not required since<br>
the ingress node will do the hashing with full packet header.<br>
<div><div><br>
On 30/07/13 11:23, &quot;Loa Andersson&quot; &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>
<br>
&gt;Xiaohu and Sri,<br>
&gt;<br>
&gt;I&#39;m struggling to understand why entropy labels would ever occur in<br>
&gt;a source routed label stack, load sharing would be be done as part of<br>
&gt;creating the source routed routes.<br>
&gt;<br>
&gt;/Loa<br>
&gt;<br>
&gt;On 2013-07-30 10:40, Xuxiaohu wrote:<br>
&gt;&gt; Totally Â agree. Â In addition, some extension to ISIS and OSPF may also<br>
&gt;&gt; be needed for advertising the ELC.<br>
&gt;&gt;<br>
&gt;&gt; Best regards,<br>
&gt;&gt;<br>
&gt;&gt; Xiaohu<br>
&gt;&gt;<br>
&gt;&gt; ------------------------------------------------------------------------<br>
&gt;&gt; *å‘ä»¶äºº:* <a href="mailto:[email-masked]" target="_blank">[email-masked]</a> [<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] ä»£è¡¨<br>
&gt;&gt; Sriganesh Kini [<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>]<br>
&gt;&gt; *å‘é€æ—¶é—´:* 2013å¹´7æœˆ30æ—¥ 16:12<br>
&gt;&gt; *åˆ°:* <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
&gt;&gt; *ä¸»é¢˜:* [Status] Comments on draft-filsfils-rtgwg-segment-routing<br>
&gt;&gt; (Entropy labels for segment routing)<br>
&gt;&gt;<br>
&gt;&gt; Hello Clarence and other authors,<br>
&gt;&gt;<br>
&gt;&gt; Current architecture does not address the issue of entropy labels. It<br>
&gt;&gt; should be listed as an open issue.<br>
&gt;&gt;<br>
&gt;&gt; At the mic yesterday, Kireeti and others brought up this issue and the<br>
&gt;&gt; related issue of label stack getting deeper. I think this is a valid<br>
&gt;&gt; concern.<br>
&gt;&gt;<br>
&gt;&gt; An EL for the entire stack is one approach. Another could be an EL per<br>
&gt;&gt; segment. Both have their advantages and disadvantages. This issue needs<br>
&gt;&gt; to be addressed.<br>
&gt;&gt;<br>
&gt;&gt; - Sri<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; status mailing list<br>
&gt;&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
&gt;&gt; <a href="https://www.ietf.org/mailman/listinfo/status" target="_blank">https://www.ietf.org/mailman/listinfo/status</a><br>
&gt;&gt;<br>
&gt;<br>
&gt;--<br>
&gt;<br>
&gt;<br>
&gt;Loa Andersson Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â email: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
&gt;Senior MPLS Expert Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
&gt;Huawei Technologies (consultant) Â  Â  phone: <a href="tel:%2B46%20739%2081%2021%2064" value="+46739812164" target="_blank">+46 739 81 21 64</a><br>
&gt;_______________________________________________<br>
&gt;status mailing list<br>
&gt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
&gt;<a href="https://www.ietf.org/mailman/listinfo/status" target="_blank">https://www.ietf.org/mailman/listinfo/status</a><br>
<br>
_______________________________________________<br>
status mailing list<br>
<a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/status" target="_blank">https://www.ietf.org/mailman/listinfo/status</a><br>
</div></div></blockquote></div><br></div></div>

--bcaec520ee1d51439204e2b94f43--

Date: Tue, 30 Jul 2013 13:54:31 +0200
From: Loa Andersson <[email-masked]>
To: [email-masked]
Subject: Re: [Status] ??: Comments on draft-filsfils-rtgwg-segment-routing (Entropy labels for segment routing)

Ruediger,

I did not mean to make a statement - I merely asked a question.

While I agree that you don't need to do <anything> just because
you can; my question was scoped to a situation where you are
doing source routing.

I got some answers that I'm currently thinking about and might be
back with further questions. Still don't see exactly how it would
easily work and what the benefits would be to include EL's in the
stack. The strict case at least seems to be at least easier to
handle with the source label stack.

/Loa

On 2013-07-30 13:42, [email-masked] wrote:
> Loa,
> 
> I think it is too early for a statement as yours below. Just because one can execute source routing one doesn't have to. Source routes may be used, if they are desireable from a provider point of view. The name of the technology to me is Segment Routing, not source routing.
> 
> Regards,
> 
> Ruediger
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: Tuesday, July 30, 2013 11:23 AM
> To: [email-masked]
> Subject: Re: [Status] ??: Comments on draft-filsfils-rtgwg-segment-routing (Entropy labels for segment routing)
> 
> Xiaohu and Sri,
> 
> I'm struggling to understand why entropy labels would ever occur in
> a source routed label stack, load sharing would be be done as part of
> creating the source routed routes.
> 
> /Loa
> 
> On 2013-07-30 10:40, Xuxiaohu wrote:
>> Totally  agree.  In addition, some extension to ISIS and OSPF may also
>> be needed for advertising the ELC.
>>
>> Best regards,
>>
>> Xiaohu
>>
>> ------------------------------------------------------------------------
>> *·¢¼þÈË:* [email-masked] [[email-masked]] ´ú±í
>> Sriganesh Kini [[email-masked]]
>> *·¢ËÍÊ±¼ä:* 2013Äê7ÔÂ30ÈÕ 16:12
>> *µ½:* [email-masked]
>> *Ö÷Ìâ:* [Status] Comments on draft-filsfils-rtgwg-segment-routing
>> (Entropy labels for segment routing)
>>
>> Hello Clarence and other authors,
>>
>> Current architecture does not address the issue of entropy labels. It
>> should be listed as an open issue.
>>
>> At the mic yesterday, Kireeti and others brought up this issue and the
>> related issue of label stack getting deeper. I think this is a valid
>> concern.
>>
>> An EL for the entire stack is one approach. Another could be an EL per
>> segment. Both have their advantages and disadvantages. This issue needs
>> to be addressed.
>>
>> - Sri
>>
>>
>> _______________________________________________
>> 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
> 

-- 

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, 30 Jul 2013 13:42:18 +0200
Accept-Language: en-US, de-DE
acceptlanguage: en-US, de-DE
Cc: [email-masked]
Subject: Re: [Status] ??: Comments on draft-filsfils-rtgwg-segment-routing (Entropy labels for segment routing)

From: AshwoodsmithPeter <[email-masked]>
To: "Dolganow, Andrew (Andrew)" <[email-masked]>
Date: Tue, 30 Jul 2013 11:18:13 +0000
Accept-Language: en-US, zh-CN
Cc: "[email-masked]" <[email-masked]>, Loa Andersson <[email-masked]>
Subject: Re: [Status] =?gb2312?b?tPC4tDogIENvbW1lbnRzIG9uIGRyYWZ0LWZpbHNmaWxz?= =?gb2312?b?LXJ0Z3dnLXNlZ21lbnQtcm91dGluZyAoRW50cm9weSBsYWJlbHMgZm9yIHNl?= =?gb2312?b?Z21lbnQgcm91dGluZyk=?X-BeenThere: [email-masked]

From: "Henderickx, Wim (Wim)" <[email-masked]>
To: Loa Andersson <[email-masked]>, "[email-masked]" <[email-masked]>
Accept-Language: nl-BE, en-US
Subject: Re: [Status] =?gb2312?b?tPC4tDogIENvbW1lbnRzIG9uIGRyYWZ0LWZpbHNmaWxz?= =?gb2312?b?LXJ0Z3dnLXNlZ21lbnQtcm91dGluZyAoRW50cm9weSBsYWJlbHMgZm9yIHNl?= =?gb2312?b?Z21lbnQgcm91dGluZyk=?X-BeenThere: [email-masked]

From: "Dolganow, Andrew (Andrew)" <[email-masked]>
To: Loa Andersson <[email-masked]>, "[email-masked]" <[email-masked]>
Accept-Language: en-US
Subject: Re: [Status] =?gb2312?b?tPC4tDogIENvbW1lbnRzIG9uIGRyYWZ0LWZpbHNmaWxz?= =?gb2312?b?LXJ0Z3dnLXNlZ21lbnQtcm91dGluZyAoRW50cm9weSBsYWJlbHMgZm9yIHNl?= =?gb2312?b?Z21lbnQgcm91dGluZyk=?X-BeenThere: [email-masked]

From: Xuxiaohu <[email-masked]>
To: Loa Andersson <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 30 Jul 2013 09:28:07 +0000
Accept-Language: zh-CN, en-US
Subject: [Status] =?gb2312?b?tPC4tDogILTwuLQ6ICBDb21tZW50cyBvbiBkcmFmdC1m?= =?gb2312?b?aWxzZmlscy1ydGd3Zy1zZWdtZW50LXJvdXRpbmcgKEVudHJvcHkgbGFiZWxz?= =?gb2312?b?IGZvciBzZWdtZW50IHJvdXRpbmcp?X-BeenThere: [email-masked]

Date: Tue, 30 Jul 2013 11:23:01 +0200
From: Loa Andersson <[email-masked]>
To: [email-masked]
Subject: Re: [Status] =?utf-8?b?562U5aSNOiAgQ29tbWVudHMgb24gZHJhZnQtZmlsc2Zp?= =?utf-8?q?ls-rtgwg-segment-routing_(Entropy_labels_for_segment_routing?= =?utf-8?q?)?X-BeenThere: [email-masked]

Xiaohu and Sri,

I'm struggling to understand why entropy labels would ever occur in
a source routed label stack, load sharing would be be done as part of
creating the source routed routes.

/Loa

On 2013-07-30 10:40, Xuxiaohu wrote:
> Totally  agree.  In addition, some extension to ISIS and OSPF may also
> be needed for advertising the ELC.
>
> Best regards,
>
> Xiaohu
>
> ------------------------------------------------------------------------
> *å‘ä»¶äºº:* [email-masked] [[email-masked]] ä»£è¡¨
> Sriganesh Kini [[email-masked]]
> *å‘é€æ—¶é—´:* 2013å¹´7æœˆ30æ—¥ 16:12
> *åˆ°:* [email-masked]
> *ä¸»é¢˜:* [Status] Comments on draft-filsfils-rtgwg-segment-routing
> (Entropy labels for segment routing)
>
> Hello Clarence and other authors,
>
> Current architecture does not address the issue of entropy labels. It
> should be listed as an open issue.
>
> At the mic yesterday, Kireeti and others brought up this issue and the
> related issue of label stack getting deeper. I think this is a valid
> concern.
>
> An EL for the entire stack is one approach. Another could be an EL per
> segment. Both have their advantages and disadvantages. This issue needs
> to be addressed.
>
> - Sri
>
>
> _______________________________________________
> 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: Xuxiaohu <[email-masked]>
To: Sriganesh Kini <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 30 Jul 2013 08:40:48 +0000
Accept-Language: zh-CN, en-US
Subject: [Status] =?gb2312?b?tPC4tDogIENvbW1lbnRzIG9uIGRyYWZ0LWZpbHNmaWxz?= =?gb2312?b?LXJ0Z3dnLXNlZ21lbnQtcm91dGluZyAoRW50cm9weSBsYWJlbHMgZm9yIHNl?= =?gb2312?b?Z21lbnQgcm91dGluZyk=?X-BeenThere: [email-masked]

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081DA577NKGEML512MBSchi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081DA577NKGEML512MBSchi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<style id="owaParaStyle">P {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</style>
</head>
<body fPStyle="1" ocsi="0">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">
<p>Totally&nbsp; agree.&nbsp; In addition, some extension to ISIS and OSPF may also be needed&nbsp;for advertising the ELC.</p>
<p>&nbsp;</p>
<p>Best regards,</p>
<p>Xiaohu</p>
<div style="FONT-FAMILY: Times New Roman; COLOR: #000000; FONT-SIZE: 16px">
<hr tabindex="-1">
<div style="DIRECTION: ltr" id="divRpF338269"><font color="#000000" size="2" face="Tahoma"><b>·¢¼þÈË:</b> [email-masked] [[email-masked]] ´ú±í Sriganesh Kini [[email-masked]]<br>
<b>·¢ËÍÊ±¼ä:</b> 2013Äê7ÔÂ30ÈÕ 16:12<br>
<b>µ½:</b> [email-masked]<br>
<b>Ö÷Ìâ:</b> [Status] Comments on draft-filsfils-rtgwg-segment-routing (Entropy labels for segment routing)<br>
</font><br>
</div>
<div></div>
<div>
<div dir="ltr"><span style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 12px">Hello Clarence and other authors,</span><br>
<div dir="ltr">
<div style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 12px" dir="ltr">
<div><br>
</div>
<div>Current architecture does not address the issue of entropy labels. It should be listed as an open issue.</div>
<div><br>
</div>
<div>At the mic yesterday, Kireeti and others brought up this issue and the related issue of label stack getting deeper. I think this is a valid concern.</div>
<div><br>
</div>
<div>An EL for the entire stack is one approach. Another could be an EL per segment. Both have their advantages and disadvantages. This issue needs to be addressed.</div>
<div><br>
</div>
<div>- Sri</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081DA577NKGEML512MBSchi_--

Sender: [email-masked]
From: Sriganesh Kini <[email-masked]>
Date: Tue, 30 Jul 2013 01:12:44 -0700
To: [email-masked]
Subject: [Status] Comments on draft-filsfils-rtgwg-segment-routing (Entropy labels for segment routing)

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

Hello Clarence and other authors,

Current architecture does not address the issue of entropy labels. It
should be listed as an open issue.

At the mic yesterday, Kireeti and others brought up this issue and the
related issue of label stack getting deeper. I think this is a valid
concern.

An EL for the entire stack is one approach. Another could be an EL per
segment. Both have their advantages and disadvantages. This issue needs to
be addressed.

- Sri

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

<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">Hello Clarence and other authors,</span><br><div dir="ltr"><div dir="ltr" style="font-family:arial,sans-serif;font-size:12.800000190734863px">

<div><br></div><div>Current architecture does not address the issue of entropy labels. It should be listed as an open issue.</div><div><br></div><div>At the mic yesterday, Kireeti and others brought up this issue and the related issue of label stack getting deeper. I think this is a valid concern.</div>

<div><br></div><div>An EL for the entire stack is one approach. Another could be an EL per segment. Both have their advantages and disadvantages. This issue needs to be addressed.</div><div><br></div><div>- Sri</div></div>

</div></div>

--047d7bea3cca3cdaff04e2b62e02--

From: "Carlos Pignataro (cpignata)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 29 Jul 2013 13:03:24 +0000
Accept-Language: en-US
Subject: [Status] Minutes for IETF87, STATUS BOF meeting

--Apple-Mail=_0D8AABEB-C129-4122-8D49-369EAFFFCCF8
Content-Type: multipart/mixed;
	boundary="Apple-Mail=_DD74BB7C-337D-454B-A22B-46E50CE3D84D"

--Apple-Mail=_DD74BB7C-337D-454B-A22B-46E50CE3D84D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi, STATUS,

Please find the minutes of today's STATUS BOF meeting attached. Comments and corrections most welcome!

Thanks,

-- Carlos.

--Apple-Mail=_DD74BB7C-337D-454B-A22B-46E50CE3D84D
Content-Disposition: attachment;
	filename=ietf87-status-minutes.html
Content-Type: text/html;
	name="ietf87-status-minutes.html"
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Language" content="en-us" />
<title>/ietf87-status</title>
</head>
<body><br
/>Agenda: <a href="http://tools.ietf.org/agenda/87/agenda-87-status.html">http://tools.ietf.org/agenda/87/agenda-87-status.html</a><br
/><br
/>Scribe: Carlos Pignataro<br
/><br
/><br
/><b><u>Stacked Tunnels for Source Routing (STATUS) BOF</u></b><br
/><br
/><b>MONDAY, July 29, 2013</b><br
/><b>1300-1500&nbsp; Monday Afternoon Session I</b><br
/><br
/><b>CHAIR(s):&nbsp; Alvaro Retana &lt;[email-masked]&gt;</b><br
/><b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; John Scudder &lt;[email-masked]&gt;</b><br
/><br
/><br
/><b>o Administrivia and Introduction&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 10 minutes</b><br
/><b>&nbsp; Chairs, Area Directors</b><br
/><ul><li>Welcome!</li
><li>We have a full agenda and tight schedule. For comments, please say your name and your comment briefly.</li
><li>There is also time for open discussion at the end.</li
><li>See the new abbreviated Note Well &lt;Jeff reads Note Well&gt;.</li
><li>BTW -- I will be shocked if there are no patents applications for the things we cover today, in fact some disclosures may have already taken place</li
><li>The goal of this BOF -- source routing has existed as long as networking, but has not been used much. The goal is to answer if we should use it more.</li
><li>Next level goal is an additional set of questions -- what use cases, which data plane, which assumtions, what management/control architecture we want, and what is a label anyway.</li></ul
><u>Questions:</u><br
/><ul><li>Jeff: Anything ADs want to say?</li
><li>Stewart: No, you said it all.</li
><li>Jeff: We are 5 minutes ahead.<br/><br
/><br/><br
/></li></ul
><b>o Use Case: Performance Engineered LSPs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 10 minutes</b><br
/><b>&nbsp; Rob Shakir</b><br
/><ul><li>I want to create LSPs in an IP/MPLS infrastructure which are routed away from SPT based on performance constraints.</li
><li>Today, we have our topology with the IGP and its metrics, and we optimize given whatever we say that metric is. But the issue is what happens when there are different services over this network.</li
><li>There are specific applications that are performance or delay sensitive -- how do we meet those requirements?</li
><li>Today, transport networks are good. But more applications require these performance requirements.</li
><li>Generalizing, these are things I could do with RSVP-TE. BUT, if I start including per-service per-flow LSPs, then the number of LSPs does not scale. The whole network never actually converges (back pressure on the head-ends RSVP-TE).</li
><li>Midpoint-state is used only for admission control (coloring), so why do we need state in the middle?</li
><li>Consequently, next approach we discuss is Segment Routing, which removes the constraints of state in the middle of the network.</li
><li>We would like to reuse existing mechanisms. Extended IGP attributes, and distributed path calculation.</li
><li>For routing with multiple services, we have PCE and we can use PCE.</li
><li>We have written this draft (with Verizon and Telecom Italia) and is pretty key to us.</li
><li>I would encourage we move forward with this one.</li></ul
><u>Questions:</u><br
/><ul><li>Ed Crabbe, Google: Disclosure. I am involved in the SR efforts. I have similar use cases to this. I have large full meshes for a variety of reasons -- service meshes to measure. SR is definitely going to help us with this and I am looking forward to it.</li
><li>Nitin, Juniper: If there is no state in the middle of the network. You do not account for how much traffic on a path (i.e., transit network is a black box), how do you manage?</li
><li>Rob: How is that so different from today?</li
><li>Nitin: Today you have reservations.</li
><li>Ed: That is not true today.</li
><li>Nitin: It is better than nothing.</li
><li>Rob: I do not have that today -- being able to deploy it it would be advantageous to have that information, so I do not know if that is a requirement.</li
><li>Someone: In SIP we are using SIP addresses for source routing. Looks nice in paper, but in practice nobody uses it in open networks. For the security reason that killed source routing in the IP space.</li
><li>Rob: The point to me is: this is whithin my operational domain, not cross-domain.<br/><br
/><br/><br
/></li></ul
><b>o Use Case: MPLS OAM&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 10 minutes</b><br
/><b>&nbsp; Ruediger Geib</b><br
/><ul><li>This is about SR OAM use case.</li
><li>The classical approach, you have many monitoring boxes (or the routers themselves), checking if there is connectivity. Smart way of dealing with ECMP also.</li
><li>If you then use Segment Routing, it simplifies a lot because you only need a single system or router dedicated to this task and you can monitor all your network.</li
><li>I do not go into details but you will figure out in detail if you work in OAM.</li
><li>It is scalable and increases availability. But basically you need one and monitor all paths in the network.</li
><li>We have in DT&nbsp; a prototype connected to our commencial network.</li
><li>Google I think also working with IP based solution, but I understand pretty much identical appraoch to what I just showed</li></ul
><u>Questions:</u><br
/><ul><li>Kireeti Kompella: You have this interesting path that goes in the diagram. So in OAM you check a connection or service to see if it is OK. If you have that path already, why can't you use that same path to test OAM?</li
><li>Ruediger: You send the result to the source, to then transmit the result to a single router.</li
><li>Kireeti: So you really want to ping from A to B, but want to start it from a different area.</li
><li>Ruediger: Yes, exactly.</li
><li>Kireeti: So telnet is not good enough a protocol that you can telnet and source an OAM?</li
><li>Ruediger: No, it makes my life hard. We do not run a small network, my NOC needs to be able to use this.</li
><li>Ed: Kireeti was joking, I guess. This is topological problem. Figure out complete set of paths that are recovering. I know we both published things on this. To be clear, Google is using this in our core. Note SR, but there is significant state in the middle.</li
><li>Nitin B., Juniper: If you ignore ECMP paths.</li
><li>Ruediger: We also covered ECMP paths.</li
><li>Nitin B.: In MPLS, George Swallwo published a draft on remote initiated MPLS Ping.</li
><li>Ruediger: Any solution should cover ECMP -- it is a MUST. Thank you.</li
><li>George Swallow: Just a comment, Remote ping is a great tool, but I saw the google paper and I think that is a really really really cool ping. You need that level of sophistication.<br/><br
/><br/><br
/></li></ul
><b>o Use Cases: ECMP based loadsharing across disjoint&nbsp;&nbsp;&nbsp; 10 minutes</b><br
/><b>&nbsp; networks, QoS based explicit routes</b><br
/><b>&nbsp; Martin Horneffer</b><br
/><ul><li>Reducing Complexity in the Network Architecture</li
><li>Comparing MPLS based on RSVP, based on LDP, and Segment Routing.<ul><li>RSVP-based: complex to setup, overlay topology</li
><li>LDP-based: Issues of having LDP and having it synchronized</li
><li>SR (with MPLS labels): Label TLV in an existing IGP -- and that is it. You can have additional complexity for some use cases, but only as much as you need.</li></ul
></li
><li>First use case: I am working on this project of Disjoint Paths.<ul><li>Sigtran traffic in the mobile network requires disjoint paths. We use MPLS FRR for fast re-route.</li
><li>The fixed network does not require disjoing paths, it is optimized for efficiency and we use IP FRR.</li
><li>What we will do to merge these two networks. Merged, it works, it can provide FRR, but it is not efficient.</li
><li>If we could tailor the IGP so that the high-bandwidth traffic takes advantage of ECMP.</li></ul
></li
><li>Second use case: locations in diffferent continents.&nbsp;<ul><li>Routing of Asia-Europ traffic, going through America, which is low latency but very expensive.</li
><li>We could send the delay sensitive only traffic that way.</li
><li>Today I could set RSVP Tunnels optimized for latency. But this is complex with RSVP and have this overlay topology (as seen from the IGP)</li
><li>If you had Segment Routing it would be much easier. I can run the IGP as I do it normally, but optimize the special case only for delay-sensitive traffic.</li></ul
></li
><li>All those use cases are mentioend in the use case draft.</li></ul
><u>Questions:</u><br
/><ul><li>Nitin B.: On slide 6, hypothetically, if someone gave you a solution that gave you no complexity and operation cost savings, would you still do SR?</li
><li>Martin: I cannot see how that could be done, if should have state in the core. Maybe you can spare the operational guys from manually configuring the Tunnels.</li
><li>Victor Lopez from Telefonica: We support this because we are using the same use cases. We have a company connected between North America and South America and we are seeing how to use SR for this.</li
><li>John: I need to cut the mike and remind that we have open discussion at the end.<br/><br
/><br/><br
/></li></ul
><b>o Use Case: Fast Reroute&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 10 minutes</b><br
/><b>&nbsp; Bruno Decraene</b><br
/><ul><li>IGP convergence is not fast enough. We are looking for a FRR technology.</li
><li>Remote LFA completely matches STATUS. We can do it with no protocol extensions but needs dynamically established T-LDP.</li
><li>Directed LFA is a solution. With Remote LFA you can still find topologies that are not covered.</li
><li>The applicability is egress or PE node protection. Protects the service node at the end of the LSP. You need a protection node mirroring.</li
><li>Protocol extensions for FRR on the other hand are required for no T-LDP sessions.</li
><li>Incremental deployment is interesting. SR FRR is interesting</li></ul
><u>Questions:</u><br
/><ul><li>John: Any questions? Going once, twice, gone.<br/><br
/><br/><br
/><br/><br
/></li></ul
><b>o Use Case: Converged Multi-network Operation&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 5 minutes</b><br
/><b>&nbsp; Victor Kuarsingh</b><br
/><ul><li>We started with a problem statement as an operator would see it. We have multiple networks that do different things and we have services that span networks.</li
><li>When you look at those networks, they were built with a specific function and we cannot change them.</li
><li>Services are stuck with those networks.</li
><li>Not all services require the same thing (e.g., QoS requirements, resiliency)</li
><li>We need lowest cost path routes. And for this we have to deal with TE.</li
><li>It is getting pretty complext. As we look at this there is no one solution, which is why we looked at this.</li
><li>The simple you can make the solution, and reducing how much state you need in your network, that is best.</li
><li>We are big in programmability -- there is no way to scale to 'N' services spanning multiple networks and manage and provision all of that manually.</li
><li>As we said, we need support for explicit path. Also FRR, and services that require different traffic treatment.</li
><li>We have different services, that need to be different</li
><li>This slide shows examples on how we stack services, domain and paths.</li
><li>Networks have been optimized for specific things but we have services crossing those diverse networks. We cannot change those, but we need to provide consistency for the service.</li
><li>We cannot afford to build 3-4 paths for each.</li
><li>Programming and SDN Interaction. Out operational models will not scale so we need to have programming and with STATUS we have an opportunity to push this to the edge, and there's a lot of advantages of that.</li
><li>We see a huge simplification. I only had 5 minutes so I went pretty fast.</li></ul
><u>Questions:</u><br
/><ul><li>John: John, we will have time to fit you in<br/><br
/><br/><br
/></li></ul
><b>Comcast use case for IPv6 SR</b><br
/><b>Brzozowski, John &lt;[email-masked]&gt;</b><br
/><ul><li>Thank you very much for allowing time.</li
><li>We want to present a Comcast use case. IPv6 is widely deployed, we have Video, we have a number of services. We have a virtualized infrastructure to delvier content services.&nbsp;</li
><li>From my point of view, this is why we see SR as a technology for us.</li
><li>We need to push this into the home.</li
><li>We feel it is transparent, working across especially our v6 environment and non-SR devices.</li
><li>We have an incremental approach.</li
><li>Here is the diagram.</li></ul
><u>Questions:</u><br
/><ul><li>Ross Callon, Juniper: I apologize I have not read. It seems you are talking about video networks and networks with a bunch of stuff. In the core you have high bandwidth, so presumably you have ASIC forwarding in the core. IPv6 should work well with MPLS. I've seen some v6 that uses a new v6 header as opposed to MPLS header for forwarding. One issue is that if we define a new header, it will take years to deply that, whereas now IPv6 works with MPLS just fine.</li
><li>... At the time v6 was being defined, vendors were saying that we needed ASICs, and the v6 people were saying: no, we need RISC processorts. So v6 seems optimized for RISC and not ASICs.</li
><li>... so what you say makes sense, but you have not talked about what headers will be there on the wire.</li
><li>... I wonder if you have comments on that.</li
><li>John Drake: The point you make is that MPLS is very common in core networks</li
><li>John S: Can you guys put a pin on that and table the discussion for later offline?</li
><li>Ross: Sure.<br/><br
/><br/><br
/></li></ul
><b>o Stacked Tunnels, OSPF/ISIS as Label Distribution&nbsp;&nbsp;&nbsp;&nbsp; 10 minutes</b><br
/><b>&nbsp; Protocols, and MPLS Architecture</b><br
/><b>&nbsp; John Drake</b><br
/><ul><li>Explicitly router tunnels are routing on a path different than the hop-by-hop path.</li
><li>The other aspect of this is LSP Hierarchy which allows you to stack labels on others.</li
><li>So you can create a stack of labels to have end to end path set up from the source.</li
><li>This is frequent in GMPLS -- the label is the same end-to-end, and that is fully compliant with the MPLS Architecture.</li
><li>RFC3031 says that a multiplicitly of label distribution protocols are OK.</li
><li>IGP neighbors can talk about LSPs that actually terminate many hops away.</li
><li>We can use RSVP or LDP to establish segments.</li
><li>Using the IGP we get nice control scaling. Once we have the local adjacency we can distribute the labels within the area.</li
><li>Unlike T-LDP we can distribute labels, so it gets rid of Targeted LDP.</li
><li>Conclussion: We think this is completely consistent with the MPLS Architecture and enhances MPLS.</li></ul
><u>Questions:</u><br
/><ul><li>Lou Berger, clarifying questions. Are the labels distributed iwth the IGP to all the area or are they scoped?</li
><li>John: All area.</li
><li>Lou: Sounds like a lot fo state.</li
><li>John: The change of state are one or two properties per link</li
><li>Lou: Plus TE</li
><li>John: Already there.</li
><li>Kireeti: I agree that all you have is in the MPLS Architecture. We just have to change the name from Multiprotocol Label Switching to Multiprotocol Label Stacking.</li
><li>Someone: Unicast or Multicast?</li
><li>John: This is unicast, but can extend.<br/><br
/><br/><br
/></li></ul
><b>o Advertising MPLS LSPs in the IGP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 10 minutes</b><br
/><b>&nbsp; draft-gredler-isis-label-advertisement</b><br
/><b>&nbsp; draft-gredler-ospf-label-advertisement</b><br
/><b>&nbsp; Hannes Gredler</b><br
/><ul><li>Two types of advertisement:</li
><li>First: desire for automatic meshing of LSPs. People like the LDP model that you turn it on, track IGP, and at the end you have the full mesh. Transport path tree is computed according to an algorithm (and you can have multiple optimizations). There have been attempts to build transport paths by the IGP with label</li
><li>I do not want to go into details, but it has been stated many times that label allocation is local significant.</li
><li>Index to label range is a pointer to where traffic is coming from. So we flip the logic and we use destination.</li
><li>Slide 6 -- consider we have this network. The local label range is strictly their local choice. It is actually pretty straight forward to compute the SPT then.</li
><li>Second: the second type of advertisement is explicit route. So we change the next hop as a chain of next hops, and we extend the ERO. For any particular label you an advertise the primary but also backup and detours. The protocol is very clean, we can probably replicate it from OSPF and ISIS.</li
><li>In June we got together with our friends at Cisco who have this Segment Routing thing coming up and supports similar requirements, so can we merge? So we took the ideas and merged them, We did that both for ISIS and for OSPF as well.</li
><li>After the draft merge, quick summary is that the protocol semantics are pretty much identical.</li
><li>There are also some differences:<ul><li>We have an MPLS way of doing things, because RFC 3031 provides enough architecture and we do not need a enw architecture.</li
><li>There's also the point of reuse. We do not want to introduce dataplane #4 in the internet for costs</li></ul
></li
><li>That's the end of my talk. Any questions?</li></ul
><u>Questions:</u><br
/><ul><li>Stephan, Orange: First, thank you for the merge of the draft. I just have one question: Why do we want to push the index-based allocation of the segments? What benefit you see?</li
><li>Hannes: MPLS networks have been deployed for a long time. Redefining semantics can be dangerous and damaging. We have seen redefining label-allocation procedures actually does damange to existing protocols.</li
><li>Stephan: I can see benetif to using network-wide labels. If you are doing netwflow, and if you have domain-wide label then you know the context of that flow.</li
><li>Hannes: Vendors have a configurable label manager so you can pre-provision identical labels and it is a local procedure.</li
><li>...I care about interoperability. So if a router does not have this it can still interoperate.</li
><li>&lt;name&gt;, France Telecom: Global labels are of advantage and I appreciate if you can get there.</li
><li>Raszuk: On the bashing of IPv6 -- there are a lot of networks that use IPv6, including Data Center, and do not require modification. BGP Vector routing does not require</li
><li>Hannes: Do not get me wrong, this is not about not supporting IPv6. It is about the v6-specific segment routing instantiation.</li
><li>Wes George: There is a draft circulating in MPLS right now which talks about what happens with MPLS when you turn off v4. This has to work in IPv6-only networks.</li
><li>Hannes: There is no fundamental issue.</li
><li>Jeff Haas, Juniper: With netflow, the current state of the art of using netflow for MPLS is that it is very complex to match the state of forwarding with the actual label value. Domain wide or not you get that.</li
><li>Hannes: Thank you.<br/><br
/><br/><br
/></li></ul
><b>o Segment Routing&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 10 minutes</b><br
/><b>&nbsp; draft-filsfils-rtgwg-segment-routing-00</b><br
/><b>&nbsp; draft-filsfils-rtgwg-segment-routing-use-cases-00</b><br
/><b>&nbsp; draft-previdi-isis-segment-routing-extensions-00</b><br
/><b>&nbsp; draft-psenak-ospf-segment-routing-extensions-00</b><br
/><b>&nbsp; draft-sivabalan-pce-segment-routing-00</b><br
/><b>&nbsp; draft-francois-rtgwg-segment-routing-frr-00</b><br
/><b>&nbsp; Clarence Filsfils</b><br
/><ul><li>Good afternoon, quick update on Segment Routing. Here's the list of folks that contributed to this.</li
><li>There's been a lot of use cases that have been presented.</li
><li>At the BOF we do not need to explain the technology. Only one slide. Generality of a segment. It is both intra or inter domain. It is from forwarding but can be abstracted. Not restricted to one instantiation.</li
><li>We have been working on an agnostic control plane. But there are request for instantiating two data planes: MPLS, and IPv6</li
><li>Productization: I presented this first time in September 2012, and have commitments after 5-6 months, on MPLS and interest on IPv6</li
><li>With all the people of the draft (inclusive), we have been meeting once or twice a week.</li
><li>We've been working until June when we met in Rome, and working together. We merged so that we have a single SR draft.</li
><li>The next is to write together the MPLS instantiation.</li
><li>Also drafts on FRR application and one more.</li
><li>This is the picture in Rome in June, two days of intensive work. In addition to reaching agrements, we quickly wanted to submit ISIS and OSPF draft before we go on vacation. Great week in Rome.</li
><li>Progress. Thanks to our collegues Hannes from Juniper. The disagreement on IPv6/SR should not be an issue. We have committed our resources to study an IPv6 isntantiaiton of SR, and we will bring this to IETF. The only point we want to underline is that we hear the request and we are funding the request, so we will bring the proposal with operators and members from academia.</li
><li>Next IETF: One of the questions -- do we need a WG? We believe we do not need it. Many use case with extensions with established protocols and WGs. We would like to have velocity and speed and use the established WGs. If there is a WG created we will support it but ask that overhead is not added.</li
><li>The use cases are many, the doc is big and we could have added more. Many thanks to all members of the team. You see the different sections of the draft.</li
><li>Conclusion: I think it's been a great experience of collaboration of operators and vendors. We see many requirements and use cases for this technology. If you look at the applicability to MPLS it is significant to drastically simplifying its deploying but also enable its true functionality.</li
><li>MPLS brought explicit routing, but 15 years later the deployment is small.&nbsp;</li
><li>In my opinion if I look at it in a natural viewpoint, it looks obvious the notion of explicit and source routing in IP is needed. We need to take into consideration the impact. We will bring to IETF ror wider review in the next few months.</li></ul
><u>Questions:</u><br
/><ul><li>John S: Any questions, comments? If not, Peter you are next.<br/><br
/><br/><br
/></li></ul
><b>o Source routing and SDN&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 10 minutes</b><br
/><b>&nbsp; draft-ashwood-sdnrg-state-reduction-00</b><br
/><b>&nbsp; Peter Ashwood-Smith</b><br
/><ul><li>In S5.2 of the segment routing use cases there is a description of the use of SR for SDN.</li
><li>We did some similations of SR in exactly this context. We simulated the ideal version of SR, not the MPLS one, but unlikelt there are differences.</li
><li>We used 36 nodes (OS3E network), the controller in Chicago, and measured the convergence time from packets arrival at the first switch router, and as you can see the green at the top is the SDN hop-by-hop convergence, and the red line is the SR, so 3 times. Very promising results.</li
><li>Next we took the simulated controller and moved it around to the location of all the switches and looked at the placement, and looked at the standard deviation of the convergence.</li
><li>The gyellow is the SDN hop-by-hop deviation and the SR is the blue. You can see 86% improvement.</li
><li>Last thing we did is exploring the network size. We multiplied link delays for various values. What we saw is a 1/R type curve.</li
><li>If you think about it like a circle, SR works in the circumpherence of the network, but hop-by-hop on the area of the circle. The ration is 1/R.</li
><li>Larger diameters give more impressive advantages.</li
><li>We are working on a "protocol oblivious forwarding" for the idealized of source routing for forwarding.&nbsp;</li
><li>That's it for me. Questions?</li></ul
><u>Questions:</u><br
/><br
/><br
/><b>o Open Discussion&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 20 minutes</b><br
/><ul><li>John S: OK, thanks for everyone that spoke up. Now we have questions to answer. I see people going to the mikes already. Now it's your chance.</li
><li>Ross Callon: If I do not think about the IPv6, what we are basically doing: In 1991 we knew source routing was important, and we came up with RSVP-TE so all nodes in the route need to agree so there's state but packets just flow. Now we are moving state into the packet, so what is the limit? Have people thought about that? Is there some point at which MTU breaks or something breaks? In the MPLS presentation there were 3 labels and you are fine.</li
><li>John S: Replies encouraged at the mike.</li
><li>Ed Crabbe: Yes, we thought about that. We have different services with different packet size distribution. We know on a per-service basis what we would use as we move to SR. The gains that we get in terms of control plane. If you have 1000s and 1000s of nodes, then you designed the network poorly.</li
><li>Someone: Regarding the IPv6 case. In our position, if the architectural benefits are tehre and simplication can be had, from an operator standpoint I thing there is value in pursuing the v6 option. We need to evaluate the architectureal benefits. For us, it adds simplification. The complexity of config is the issue we need help with.</li
><li>Clarence: The question is very important. If you look at it theoretically, it fails, you can think of 24 labels. The real gain is by looking at the real operator deployment. If you look at the use cases today, will be used with 2 or 3 labels. For exampel, FRR is proven to be solved with 2 or 3 labels. Then you have performance and add a label. It is rara you need mroe than 3-4 labels. But even say you need 6-7, even in that case it's not issue. The process that drives the instantation of this is a capacity planning process. Modeling the network, the traffic, and the constraints and capabilities of the node. One of the things we learn in the PCE draft is how many labels you can include.</li
><li>Academically, the worst case is catastrophe if someone puts 26 labels it won't work. But if you look at it from a use case bases, the benefits are huge.</li
><li>Peter: I agree. Also, we are the IETF, and if need to compress labels we can.</li
><li>John S: What about the network you modeled?</li
><li>Peter: Diameter of 5</li
><li>John: With enough thrust even pigs could fly?</li
><li>Peter: Even MPLS flies.</li
><li>Ross Callon: We are here in a working group forming BOFs. There's been a list of 6 WGs, but BFD as well, so 7. So seems to me that we need work to be done here and we need the coordination. There is work which is how you carry in ISIS, and ISIS will look at that. But seems to be there ought to be a Status or SR WG looking at all the pieces.</li
><li>Kireeti: Yes, it's an old idea, but we do it already, it is called RSVP-TE. It was a joking comment about switching versus stacking. When we saw this there were questions on the label stack and global labels. When we added entropy labels and special purpose labels, people asked about depth of stack. So that question has not been answered. Regarding use cases, one use case makes a alot of sense, not all use cases make sense. Because we have a new technology does not mean need to solve. We need to be very careful in this WG and start with one or two use cases. Last comment, I've seen many presentations about removing complexity. Be very careful: you are not removing complexity, you are moving complexity around.</li
><li>&lt;applauses&gt;</li
><li>John S: I echo that.</li
><li>Operator A: Larger network that can be a problem. You are moving complexity somewhere else.</li
><li>Ed Crabbe: Working in Google I am biased. I totally agree with moving complexity. But moving complexity into a platform that can handle it better is not necessarily a bad thing.</li
><li>Erik N.: I think there is commonality around MPLS and some discussion about IPv6. But there was one thing in John's presentation that was more out there taking this to the home. So I am trying to understand the architectural implications. Is it a service provider use case</li
><li>John: Great question, we would be asking that if this was a charter forming exercise.</li
><li>Peter: Worked really hard on IPv6. Having source packets can be used in many ways. What about the home. We would be crazy to not let the IETF develop the best tool, and the user can choose. We try to make the best iInternet.</li
><li>Alia: On the "should it be a BOF or broken out"? There are different pieces. The MPLS piece is well understoof, the IPv6 not so much. It seems like a lot of the architecture and use case drafts are coming at RTGWG, which is used as an incubator. The argument about "is there a WG for Status and protocol pieces on WGs" has evolved into "does architecture go to RTGWG", for doign work we need working groups.</li
><li>Hannes: To Peter;s comment. What sense does it make to replicate tag-switching semantics into IP just to call it "label free"? That's replicating work. We've done it once.</li
><li>Peter: Last time I checked we do not have NNIs. We need an architecture.</li
><li>Hannes: Look at the comcast requirements. At no point they are asking for source routing end-to-end. They are asking for IPv6 end to end.</li
><li>John S.: Last one.</li
><li>Peter: On the point of WG or not, seems like a common place seems useful instead of going in many WGs.<br/><br
/><br/><br
/></li></ul
><b>o Wrap-up&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 5 minutes</b><br
/><b>&nbsp; Chairs, Area Directors</b><br
/><ul><li>Let's poll the room on some of these stuff, with show of hands.</li
><li>Do we want to take this work on? Who is for? Like a forest. Who things we shouldn't? No hands &lt;that I could see&gt;. We have the answer on that one.</li
><li>Next one is: OK, how? Is it a WG or do we have enough WGs thank you very much. And if it's a WG we can ask about its nature.</li
><li>Eliot: Alia raised another choice about RTGWG.</li
><li>Stewart: First question is: should there be an explicit WG to work on this. Those who think yes: small number. Those who think not: larger number.</li
><li>...Where is the architecture: Yes for RTGWG: many hands. Those for no: one/two hands</li
><li>... one of the chairs.</li
><li>John S: Do we need an MPLS dataplane?</li
><li>Stewart: MPLS dataplane. Yes: many hands. No: fewer or none.</li
><li>... IPv6. yes: medium. no: tiny.</li
><li>... dataplane other than MPLS:</li
><li>... undecided: 8 hands.</li
><li>... who wants a source-routed IP dataplane? tiny number.</li
><li>John: I think we actually answered the set of questions we can answer in the amount we have.</li
><li>Stewart: Where are the use cases worked on? Do people want those in RTGWG?</li
><li>John: We should ask the RTG WG too.</li
><li>Stewart: The IESG will make that desicion. The particular we talk about has that scope.</li
><li>Alia: I am concerned that use cases + architecture will be more than "short simple small term" documents.</li
><li>John: I heard from others that this is hot and needs to move quickly. If you add to existing RTGWG would not mean fast.</li
><li>Kireeti: The question should -- do we want a single WG? and then ask "existing or new one"? I think the questions were confusing.</li
><li>Stewart: do you want us to creeate home for architecture and use cases? some charted coming to existence?</li
><li>Someone: We do not understand.</li
><li>John S: we are now out of time -- thank you everyone.<br/><br
/><br/><br
/></li></ul
></body>
</html>

--Apple-Mail=_DD74BB7C-337D-454B-A22B-46E50CE3D84D
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

--Apple-Mail=_DD74BB7C-337D-454B-A22B-46E50CE3D84D--

--Apple-Mail=_0D8AABEB-C129-4122-8D49-369EAFFFCCF8
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=_0D8AABEB-C129-4122-8D49-369EAFFFCCF8--

From: <[email-masked]>
To: <[email-masked]>
Date: Mon, 29 Jul 2013 10:13:25 +0200
Accept-Language: en-US, de-DE
acceptlanguage: en-US, de-DE
Cc: [email-masked]
Subject: Re: [Status] STATUS agenda uploaded

John,

I'll try to finish my presentation within 5 minutes too.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Scudder
Sent: Wednesday, July 17, 2013 3:21 PM
To: [email-masked]
Subject: [Status] STATUS agenda uploaded

The tentative STATUS agenda has been uploaded: http://www.ietf.org/proceedings/87/agenda/agenda-87-status

If you requested agenda time and weren't turned down, please check your slot and send any corrections to the chairs. No presenter received more time than the minimum he requested. In some cases we allocated less than that, sorry. You should expect you will NOT be allowed to run over time, although note there is a long "open discussion" slot at the end of the meeting. For this reason, presenters should plan to keep their presentations short and to the point. "To the point" means, specifically, helping to answer one or more of the questions listed in the "BoF will seek to address the following questions" section of the BOF announcement (http://tools.ietf.org/bof/trac/). In general, a packet-header level of detail would be inappropriate.

Presenters should have their presentations to the chairs no later than noon EDT this coming Monday, June 22. Those who haven't sent in slides by then may lose their slot! There are others who want your time. Also, please make sure your slides have page numbers so that remote listeners can keep track.

Those planning to attend the BOF should also note that we will start at 13:00 sharp so plan your lunch accordingly.

Finally, we would very much appreciate help with note-taking and Jabber scribing. Please volunteer your services in exchange for the undying gratitude of your peers. Note-takers may elect to cover only part of the meeting (please tell us what part you can't cover). The Jabber scribe needs to update the Jabber room with information such as what slide is being projected and (most important) to convey questions from the Jabber room to the mic during Q/A. A running transcript to Jabber is not needed.

Thanks,

--John

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

From: "John G. Scudder" <[email-masked]>
Date: Mon, 29 Jul 2013 09:32:01 +0200
To: "Brzozowski, John" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] Comcast use cases for STATUS

--Apple-Mail=_88619D11-F202-4F1D-B425-B5571AB24A02
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

Folks,

Although we don't have speaking time in the agenda, I've uploaded John and Frank's slides to the meeting materials (https://datatracker.ietf.org/meeting/87/materials.html) so they'll be available along with the rest of the presentations (that are there too).

--John
--Apple-Mail=_88619D11-F202-4F1D-B425-B5571AB24A02
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset="us-ascii"

<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Folks,<div><br></div><div>Although we don't have speaking time in the agenda, I've uploaded John and Frank's slides to the meeting materials (<a href="https://datatracker.ietf.org/meeting/87/materials.html">https://datatracker.ietf.org/meeting/87/materials.html</a>) so they'll be available along with the rest of the presentations (that are there too).</div><div><br></div><div>--John</div></body></html>
--Apple-Mail=_88619D11-F202-4F1D-B425-B5571AB24A02--

From: "Frank Brockners (fbrockne)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 29 Jul 2013 07:01:14 +0000
Accept-Language: de-DE, en-US
Cc: "Fabio Maino \(fmaino\)" <[email-masked]>, "Darrel Lewis \(darlewis\)" <[email-masked]>, "Alvaro Retana \(aretana\)" <[email-masked]>, "Shwetha Bhandari \(shwethab\)" <[email-masked]>, "John G.Scudder" <[email-masked]>
Subject: [Status] Overlay-Underlay correlation use-case discussion for STATUS

--_004_B3C8C1D36EDE59418C7AC4D5523B208A22EB54BAxmbalnx06ciscoc_
Content-Type: multipart/alternative;
	boundary="_000_B3C8C1D36EDE59418C7AC4D5523B208A22EB54BAxmbalnx06ciscoc_"

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

Folks,

similar to John Brzozowski, we were also hoping to get some time on the agenda to discuss use-cases related to overlay-underlay correlation at the STATUS BoF - unfortunately we seem to share fate with John. We also thought that it would be useful to share the slides at least - see attached.

If interested, you might also want to have a look at http://www.ietf.org/id/draft-brockners-lisp-sr-00.txt - which discusses how the combination of LISP and Segment-Routing with IPv6 transport could be used in this context. The I-D describes extensions to LISP to enable a LISP mapping system to communicate a list of segment identifiers to the encapsulating router for purposes of traffic steering in the underlay or request the transport network to record the list of segments (nodal segments or adjacency segments) a particular packet or set of packets traverses in the transport network.

Looking forward to the discussions at the BoF.

Thanks, Frank

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

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@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:11.0pt;
	font-family:"Calibri","sans-serif";}
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.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;}
@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]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoPlainText">Folks,<o:p></o:p></p>
<p class="MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class="MsoPlainText">similar to John Brzozowski, we were also hoping to get some time on the agenda to discuss use-cases related to overlay-underlay correlation at the STATUS BoF &#8211; unfortunately we seem to share fate with John. We also thought that it would
 be useful to share the slides at least &#8211; see attached. <o:p></o:p></p>
<p class="MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class="MsoPlainText">If interested, you might also want to have a look at <a href="http://www.ietf.org/id/draft-brockners-lisp-sr-00.txt">
http://www.ietf.org/id/draft-brockners-lisp-sr-00.txt</a> - which discusses how the combination of LISP and Segment-Routing with IPv6 transport could be used in this context. The I-D describes extensions to LISP to enable a LISP mapping system to communicate
 a list of segment identifiers to the encapsulating router for purposes of traffic steering in the underlay or request the transport network to record the list of segments (nodal segments or adjacency segments) a particular packet or set of packets traverses
 in the transport network.<o:p></o:p></p>
<p class="MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class="MsoPlainText">Looking forward to the discussions at the BoF.<o:p></o:p></p>
<p class="MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Thanks, Frank<o:p></o:p></p>
</div>
</body>
</html>

--_000_B3C8C1D36EDE59418C7AC4D5523B208A22EB54BAxmbalnx06ciscoc_--

--_004_B3C8C1D36EDE59418C7AC4D5523B208A22EB54BAxmbalnx06ciscoc_
Content-Type: application/pdf;
	name="ietf-status_overlay-underlay_28jul2013.pdf"
Content-Description: ietf-status_overlay-underlay_28jul2013.pdf
Content-Disposition: attachment;
	filename="ietf-status_overlay-underlay_28jul2013.pdf"; sizeE4497;
	creation-date="Mon, 29 Jul 2013 06:54:19 GMT";
	modification-date="Mon, 29 Jul 2013 07:00:07 GMT"
Content-Transfer-Encoding: base64

--_004_B3C8C1D36EDE59418C7AC4D5523B208A22EB54BAxmbalnx06ciscoc_--

From: "Brzozowski, John" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 29 Jul 2013 00:04:15 +0000
Accept-Language: en-US
Subject: [Status] Comcast use cases for STATUS

--_002_BD87928F6BFAEF4EBEB883E1C4F587723B95CBFCPACDCEXMB01cabl_
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[email-masked]>
Content-Transfer-Encoding: quoted-printable

Folks,

We were hoping to get some time to discuss the attached during the BOF
Monday.  At this stage it does not look like this will happen, either way
we thought it would be useful to share these slides.  We look forward to
the BOF and can elaborate on our use cases during the meeting as time
permits.

Thank you,

John
=========================================
John Jason Brzozowski
Comcast Cable
m) 609-377-6594
o) 484-962-0060
w) www.comcast6.net
e) [email-masked]
=========================================

--_002_BD87928F6BFAEF4EBEB883E1C4F587723B95CBFCPACDCEXMB01cabl_
Content-Type: application/pdf; name="comcast IPv6 SR use case IETF 87.pdf"
Content-Description: comcast IPv6 SR use case IETF 87.pdf
Content-Disposition: attachment;
	filename="comcast IPv6 SR use case IETF 87.pdf"; size8542;
	creation-date="Mon, 29 Jul 2013 00:04:15 GMT";
	modification-date="Mon, 29 Jul 2013 00:04:15 GMT"
Content-ID: <[email-masked]>
Content-Transfer-Encoding: base64

--_002_BD87928F6BFAEF4EBEB883E1C4F587723B95CBFCPACDCEXMB01cabl_--

From: Hannes Gredler <[email-masked]>
Date: Thu, 25 Jul 2013 17:40:27 +0200
To: Xuxiaohu <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Robert Raszuk <[email-masked]>, Peter Psenak <[email-masked]>
Subject: Re: [Status] =?utf-8?b?562U5aSNOiAg562U5aSNOiAg562U5aSNOiAgIGZ3ZDog?= =?utf-8?q?New_Version_Notification_for_draft-xu-rtgwg-global-label-adv-00?= =?utf-8?q?.txt?X-BeenThere: [email-masked]

On Jul 25, 2013, at 11:15 AM, Xuxiaohu wrote:

[ … ]

>>>> What does the SPT label mean?
>>> 
>>> an SPT label  is a label inside a label block. the actual label
>>> is determined by an index advertised by egress routers.
>>> the path to the egress router gets determined using an SPT
>>> calculation.
>> 
>> It uses the trick which has been used by BGP-based VPLS solution. Interesting.
> 
> In this way, the labels would be locally significant. Then how to achieve source routing by using stacked MPLS tunnels ?

SPT labels are used complimentary to 1-hop strict labels
(which are used for explicit routing)

in fact SPT labels can be seen as a way of compressing the
label-stack. lets say you have a given path with <N> segments
to a destination. what you can then do is to replace some of the <N>
segments with corresponding SPT labels.

furthermore the draft allows to have <M> algos infrastructure labels.
i.e. SPT(IGP metric), SPT(latency), SPT(TE-metric), MRT(red), MRT(blue) etc.
that way you increase the likelihood of finding a corresponding shared
path segment to replace an explicit segment.

the idea for multiple algos is that there aren't many dimensions to
optimize a network for (latency, utilization, bandwidth).

pre-computing all those topologies will give you
an "instruction set" for guiding your traffic with the most
minimal instructions possible.

/hannes

From: Hannes Gredler <[email-masked]>
Date: Thu, 25 Jul 2013 17:28:53 +0200
To: Xuxiaohu <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Robert Raszuk <[email-masked]>, Peter Psenak <[email-masked]>
Subject: Re: [Status] =?utf-8?b?562U5aSNOiAg562U5aSNOiAgIGZ3ZDogTmV3IFZlcnNp?= =?utf-8?q?on_Notification_for_draft-xu-rtgwg-global-label-adv-00.txt?X-BeenThere: [email-masked]

On Jul 25, 2013, at 10:43 AM, Xuxiaohu wrote:
>>> What does the SPT label mean?
>> 
>> an SPT label  is a label inside a label block. the actual label
>> is determined by an index advertised by egress routers.
>> the path to the egress router gets determined using an SPT
>> calculation.
> 
> It uses the trick which has been used by BGP-based VPLS solution. Interesting.

precisely: BGP-VPLS with reversed semantics -

BGP-VPLS use source semantics (where does it come from)
SPT-labels use destination semantics (where does it go to)

/hannes

From: Hannes Gredler <[email-masked]>
Date: Thu, 25 Jul 2013 09:39:59 +0200
To: Xuxiaohu <[email-masked]>
Cc: [email-masked], Robert Raszuk <[email-masked]>, Peter Psenak <[email-masked]>
Subject: Re: [Status] fwd: New Version Notification for draft-xu-rtgwg-global-label-adv-00.txt

xuxiaohu,

the best proposal i have seen so far for resolving potential clashes
with global labels is roberts draft:

http://tools.ietf.org/html/draft-raszuk-mpls-domain-wide-labels-00

the draft proposes to use a context label for keying off in a separate
'domain-wide' label space - i.e. no clash with anybody in the networking
doing local label allocation.

note that i am still not convinced that we need domain-wide labels
(if we have SPT labels as per the latest SR protocol extensions).

/hannes

On Jul 23, 2013, at 3:06 AM, Xuxiaohu wrote:

> Peter,
> 
>> -----é‚®ä»¶åŽŸä»¶-----
>> å‘ä»¶äºº: Peter Psenak [mailto:[email-masked]]
>> å‘é€æ—¶é—´: 2013å¹´7æœˆ22æ—¥ 19:07
>> æ”¶ä»¶äºº: Xuxiaohu
>> æŠ„é€: [email-masked]
>> ä¸»é¢˜: Re: [Status] fwd: New Version Notification for
>> draft-xu-rtgwg-global-label-adv-00.txt
>> 
>> Xiaohu,
>> 
>> On 7/22/13 05:19 , Xuxiaohu wrote:
>> 
>>>> 
>>>> - nothing in existing SR drafts prevents you to advertise SIDs/labels
>>>> from mapping server even for prefixes connected to SR capable routers.
>>> 
>>> Yes, it doesn't prevent that case explicitly. However, I haven't seen any
>> description of that case in the existing SR drafts.
>> 
>> does not mean you can not do it.
> 
> 
>>> 
>>> As you pointed out, the flooding scope of the OSPFv2 Extended Prefix Opaque
>> DEPENDS on the content inside the LSA in the SR draft. However, In my draft,
>> the flooding scope of the OSPFv2 Prefix Opaque LSA DOESN'T DEPEND on the
>> content inside the LSA.
>> 
>> given that OSPFv2 Extended Prefix Opaque LSA as defined in existing OSPF
>> SR draft allows you to do what you need, there is no need to define a
>> new LSA.
> 
> The major difference lies in the TLVs and sub-TLVs contained in that prefix specific opaque LSA rather than the opaque LSA itself which only needs a Opaque type code to be assigned.
> 
> Best regards,
> Xiaohu
> 
>> regards,
>> Peter
>> 
>>> 
>>> Best regards,
>>> Xiaohu
>>> 
> 
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: Xuxiaohu <[email-masked]>
To: Robert Raszuk <[email-masked]>
Date: Thu, 25 Jul 2013 09:33:02 +0000
Accept-Language: zh-CN, en-US
Cc: Hannes Gredler <[email-masked]>, "[email-masked]" <[email-masked]>, Peter Psenak <[email-masked]>
Subject: [Status] =?gb2312?b?tPC4tDogILTwuLQ6ILTwuLQ6ILTwuLQ6IGZ3ZDogTmV3?= =?gb2312?b?IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC14dS1ydGd3Zy1nbG9i?= =?gb2312?b?YWwtbGFiZWwtYWR2LTAwLnR4dA=?X-BeenThere: [email-masked]

Sender: [email-masked]
Date: Thu, 25 Jul 2013 11:21:51 +0200
From: Robert Raszuk <[email-masked]>
To: Xuxiaohu <[email-masked]>
Cc: Hannes Gredler <[email-masked]>, "[email-masked]" <[email-masked]>, Peter Psenak <[email-masked]>
Subject: Re: [Status] =?gb2312?b?tPC4tDogtPC4tDogtPC4tDogZndkOiBOZXcgVmVyc2lv?= =?gb2312?b?biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXh1LXJ0Z3dnLWdsb2Jh?= =?gb2312?b?bC1sYWJlbC1hZHYtMDAudHh0?X-BeenThere: [email-masked]

Xu,

> In this way, the labels would be locally significant. Then how to achieve source
> routing by using stacked MPLS tunnels ?

With SPT label space is local, but label value and meaning is domain
wide. That's the beauty of it. Remember you are flooding ranges/block
as well as SID in IGP so your peers know it.

But It does add complexity in troubleshooting and operation :(.

Cheers,
R.

From: Xuxiaohu <[email-masked]>
To: Xuxiaohu <[email-masked]>, Hannes Gredler <[email-masked]>
Date: Thu, 25 Jul 2013 09:15:19 +0000
Accept-Language: zh-CN, en-US
Cc: "[email-masked]" <[email-masked]>, Robert Raszuk <[email-masked]>, Peter Psenak <[email-masked]>
Subject: [Status] =?utf-8?b?562U5aSNOiAg562U5aSNOiAg562U5aSNOiAgIGZ3ZDog?= =?utf-8?q?New_Version_Notification_for_draft-xu-rtgwg-global-label-adv-00?= =?utf-8?q?.txt?X-BeenThere: [email-masked]

From: Xuxiaohu <[email-masked]>
To: Hannes Gredler <[email-masked]>
Date: Thu, 25 Jul 2013 08:43:07 +0000
Accept-Language: zh-CN, en-US
Cc: "[email-masked]" <[email-masked]>, Robert Raszuk <[email-masked]>, Peter Psenak <[email-masked]>
Subject: [Status] =?utf-8?b?562U5aSNOiAg562U5aSNOiAgIGZ3ZDogTmV3IFZlcnNp?= =?utf-8?q?on_Notification_for_draft-xu-rtgwg-global-label-adv-00.txt?X-BeenThere: [email-masked]

Sender: [email-masked]
Date: Thu, 25 Jul 2013 10:22:36 +0200
From: Robert Raszuk <[email-masked]>
To: Xuxiaohu <[email-masked]>
Cc: Hannes Gredler <[email-masked]>, "[email-masked]" <[email-masked]>, Peter Psenak <[email-masked]>
Subject: Re: [Status] =?utf-8?b?562U5aSNOiBmd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh?= =?utf-8?q?tion_for_draft-xu-rtgwg-global-label-adv-00.txt?X-BeenThere: [email-masked]

> Yes, there is no clash with existing transport or application labels which
> are locally significant. However, you still need some mechanism to ensure
> that a given domain-wide labels would not be assigned to different FECs
> (i.e., different node segments).

You use the same mechanis as you use today to assign IPv4 or IPv6
prefix and make sure there is no overlap or duplication within your
IGP flooding scope.

Cheers,
R.

From: Hannes Gredler <[email-masked]>
Date: Thu, 25 Jul 2013 10:20:00 +0200
To: Xuxiaohu <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Robert Raszuk <[email-masked]>, Peter Psenak <[email-masked]>
Subject: Re: [Status] =?utf-8?b?562U5aSNOiAgIGZ3ZDogTmV3IFZlcnNpb24gTm90aWZp?= =?utf-8?q?cation_for_draft-xu-rtgwg-global-label-adv-00.txt?X-BeenThere: [email-masked]

On Jul 25, 2013, at 10:07 AM, Xuxiaohu wrote:

> Hi Hannes,
> 
>> -----é‚®ä»¶åŽŸä»¶-----
>> å‘ä»¶äºº: Hannes Gredler [mailto:[email-masked]]
>> å‘é€æ—¶é—´: 2013å¹´7æœˆ25æ—¥ 15:40
>> æ”¶ä»¶äºº: Xuxiaohu
>> æŠ„é€: Peter Psenak; [email-masked]; Robert Raszuk
>> ä¸»é¢˜: Re: [Status] fwd: New Version Notification for
>> draft-xu-rtgwg-global-label-adv-00.txt
>> 
>> xuxiaohu,
>> 
>> the best proposal i have seen so far for resolving potential clashes
>> with global labels is roberts draft:
>> 
>> http://tools.ietf.org/html/draft-raszuk-mpls-domain-wide-labels-00
>> 
>> the draft proposes to use a context label for keying off in a separate
>> 'domain-wide' label space - i.e. no clash with anybody in the networking
>> doing local label allocation.
> 
> Yes, there is no clash with existing transport or application labels which are locally significant. However, you still need some mechanism to ensure that a given domain-wide labels would not be assigned to different FECs (i.e., different node segments).

yes and that mechanism is administrative policy. if you treat a MPLS
label as global identifier you have to ensure that it does
to get allocated twice.

>> note that i am still not convinced that we need domain-wide labels
>> (if we have SPT labels as per the latest SR protocol extensions).
> 
> What does the SPT label mean?

an SPT label  is a label inside a label block. the actual label
is determined by an index advertised by egress routers.
the path to the egress router gets determined using an SPT
calculation.

see

http://tools.ietf.org/html/draft-previdi-isis-segment-routing-extensions-02
http://tools.ietf.org/html/draft-psenak-ospf-segment-routing-extensions-02

and

http://tools.ietf.org/html/draft-gredler-isis-label-advertisement-03
http://tools.ietf.org/html/draft-gredler-ospf-label-advertisement-03

for manifestations of this.

>> On Jul 23, 2013, at 3:06 AM, Xuxiaohu wrote:
>> 
>>> Peter,
>>> 
>>>> -----é‚®ä»¶åŽŸä»¶-----
>>>> å‘ä»¶äºº: Peter Psenak [mailto:[email-masked]]
>>>> å‘é€æ—¶é—´: 2013å¹´7æœˆ22æ—¥ 19:07
>>>> æ”¶ä»¶äºº: Xuxiaohu
>>>> æŠ„é€: [email-masked]
>>>> ä¸»é¢˜: Re: [Status] fwd: New Version Notification for
>>>> draft-xu-rtgwg-global-label-adv-00.txt
>>>> 
>>>> Xiaohu,
>>>> 
>>>> On 7/22/13 05:19 , Xuxiaohu wrote:
>>>> 
>>>>>> 
>>>>>> - nothing in existing SR drafts prevents you to advertise SIDs/labels
>>>>>> from mapping server even for prefixes connected to SR capable routers.
>>>>> 
>>>>> Yes, it doesn't prevent that case explicitly. However, I haven't seen any
>>>> description of that case in the existing SR drafts.
>>>> 
>>>> does not mean you can not do it.
>>> 
>>> 
>>>>> 
>>>>> As you pointed out, the flooding scope of the OSPFv2 Extended Prefix
>> Opaque
>>>> DEPENDS on the content inside the LSA in the SR draft. However, In my
>> draft,
>>>> the flooding scope of the OSPFv2 Prefix Opaque LSA DOESN'T DEPEND on the
>>>> content inside the LSA.
>>>> 
>>>> given that OSPFv2 Extended Prefix Opaque LSA as defined in existing OSPF
>>>> SR draft allows you to do what you need, there is no need to define a
>>>> new LSA.
>>> 
>>> The major difference lies in the TLVs and sub-TLVs contained in that prefix
>> specific opaque LSA rather than the opaque LSA itself which only needs a
>> Opaque type code to be assigned.
>>> 
>>> Best regards,
>>> Xiaohu
>>> 
>>>> regards,
>>>> Peter
>>>> 
>>>>> 
>>>>> Best regards,
>>>>> Xiaohu
>>>>> 
>>> 
>>> _______________________________________________
>>> 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: Xuxiaohu <[email-masked]>
To: Hannes Gredler <[email-masked]>
Date: Thu, 25 Jul 2013 08:07:06 +0000
Accept-Language: zh-CN, en-US
Cc: "[email-masked]" <[email-masked]>, Robert Raszuk <[email-masked]>, Peter Psenak <[email-masked]>
Subject: [Status] =?utf-8?b?562U5aSNOiAgIGZ3ZDogTmV3IFZlcnNpb24gTm90aWZp?= =?utf-8?q?cation_for_draft-xu-rtgwg-global-label-adv-00.txt?X-BeenThere: [email-masked]

From: Hannes Gredler <[email-masked]>
Date: Thu, 25 Jul 2013 09:39:59 +0200
To: Xuxiaohu <[email-masked]>
Cc: [email-masked], Robert Raszuk <[email-masked]>, Peter Psenak <[email-masked]>
Subject: Re: [Status] fwd: New Version Notification for draft-xu-rtgwg-global-label-adv-00.txt

xuxiaohu,

the best proposal i have seen so far for resolving potential clashes
with global labels is roberts draft:

http://tools.ietf.org/html/draft-raszuk-mpls-domain-wide-labels-00

the draft proposes to use a context label for keying off in a separate
'domain-wide' label space - i.e. no clash with anybody in the networking
doing local label allocation.

note that i am still not convinced that we need domain-wide labels
(if we have SPT labels as per the latest SR protocol extensions).

/hannes

On Jul 23, 2013, at 3:06 AM, Xuxiaohu wrote:

> Peter,
> 
>> -----é‚®ä»¶åŽŸä»¶-----
>> å‘ä»¶äºº: Peter Psenak [mailto:[email-masked]]
>> å‘é€æ—¶é—´: 2013å¹´7æœˆ22æ—¥ 19:07
>> æ”¶ä»¶äºº: Xuxiaohu
>> æŠ„é€: [email-masked]
>> ä¸»é¢˜: Re: [Status] fwd: New Version Notification for
>> draft-xu-rtgwg-global-label-adv-00.txt
>> 
>> Xiaohu,
>> 
>> On 7/22/13 05:19 , Xuxiaohu wrote:
>> 
>>>> 
>>>> - nothing in existing SR drafts prevents you to advertise SIDs/labels
>>>> from mapping server even for prefixes connected to SR capable routers.
>>> 
>>> Yes, it doesn't prevent that case explicitly. However, I haven't seen any
>> description of that case in the existing SR drafts.
>> 
>> does not mean you can not do it.
> 
> 
>>> 
>>> As you pointed out, the flooding scope of the OSPFv2 Extended Prefix Opaque
>> DEPENDS on the content inside the LSA in the SR draft. However, In my draft,
>> the flooding scope of the OSPFv2 Prefix Opaque LSA DOESN'T DEPEND on the
>> content inside the LSA.
>> 
>> given that OSPFv2 Extended Prefix Opaque LSA as defined in existing OSPF
>> SR draft allows you to do what you need, there is no need to define a
>> new LSA.
> 
> The major difference lies in the TLVs and sub-TLVs contained in that prefix specific opaque LSA rather than the opaque LSA itself which only needs a Opaque type code to be assigned.
> 
> Best regards,
> Xiaohu
> 
>> regards,
>> Peter
>> 
>>> 
>>> Best regards,
>>> Xiaohu
>>> 
> 
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: Xuxiaohu <[email-masked]>
To: Saku Ytti <[email-masked]>
Date: Wed, 24 Jul 2013 02:45:31 +0000
Accept-Language: zh-CN, en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] fwd: New Version Notification for draft-xu-rtgwg-global-label-adv-00.txt

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

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

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D8681NKGEML512MBSchi_--

From: [email-masked]
Full-name: texaswritworks
Date: Tue, 23 Jul 2013 17:30:22 -0400 (EDT)
To: [email-masked]
X-AOL-SCOLL-URL_COUNT: 0  
x-aol-sid: 3039ac1d33c951eef5ef34ed
Subject: Re: [Status] status Digest, Vol 2, Issue 11
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <status.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/status>, <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/status>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/status>, <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Tue, 23 Jul 2013 21:30:33 -0000

--part1_68c4a.3e3e6051.3f204fee_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

 
Adobe nor Foxit will open this file because it says it is  "damaged?"

David C. Bolton

Certified  Paralegal
Texas Writ Works
6804-E Hwy 6 South #525
Houston, Texas  77083
(832) 794-3787
Fax: (281)  277-8374
[email-masked]

DISCLAIMER: Texas Writ Works is  a pro se document research and preparation 
service only. We are not  attorneys and do not hire attorneys. TWW will not 
engage in the  unauthorized practice of law. TWW will refer you to an 
attorney upon  written request.  

In a message dated 7/23/2013 2:02:31 P.M. Central Daylight Time,  
[email-masked] writes:

[This e-mail contains a MIME (Multipurpose Internet Mail  Extensions) file. 
The file was specially formatted to be sent over the  Internet. For more 
information on opening the attached file, go to  Keyword:  MIME.]

--part1_68c4a.3e3e6051.3f204fee_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>AOL Email</TITLE>
<META content="text/html; charset=US-ASCII" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 10.00.9200.16635">
<META name=Stationery 
content=http://cdn-cf.aol.com/se/stationery/objts/paper-st/clouds.htm></HEAD>
<BODY style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; COLOR: #000000" bottomMargin=0 
leftMargin=0 rightMargin=0 topMargin=0>
<DIV id=role_document>
<TABLE id=role_layout height="100%" cellSpacing=0 cellPadding=7 width="100%" 
align=center 
background=http://cdn-cf.aol.com/se/stationery/objts/paper-st/paper/stationery.466-1250.clouds 
border=0>
  <TBODY>
  <TR height="100%">
    <TD width="100%">
      <DIV id=role_body 
      style="FONT-SIZE: 10pt; HEIGHT: 100%; FONT-FAMILY: Arial; COLOR: #000000">
      <DIV>Adobe nor Foxit will open this file because it says it is 
      "damaged?"</DIV>
      <DIV>&nbsp;</DIV>
      <DIV>&nbsp;</DIV>
      <DIV><FONT lang=0 size=3 face="Times New Roman TUR" FAMILY="SERIF" 
      PTSIZE="12"><B>David C. Bolton</FONT><FONT lang=0 color=#000000 size=2 
      face="Times New Roman TUR" FAMILY="SERIF" PTSIZE="10"></B><BR>Certified 
      Paralegal<BR>Texas Writ Works<BR>6804-E Hwy 6 South #525<BR>Houston, Texas 
      77083<BR>(832) 794-3787<BR>Fax: (281) 
      277-8374<BR>[email-masked]<BR><BR>DISCLAIMER: Texas Writ Works is 
      a pro se document research and preparation service only. We are not 
      attorneys and do not hire attorneys. TWW will not engage in the 
      unauthorized practice of law. TWW will refer you to an attorney upon 
      written request. 
      <DIV>&nbsp;</DIV>
      <DIV>
      <DIV>In a message dated 7/23/2013 2:02:31 P.M. Central Daylight Time, 
      [email-masked] writes:</DIV>
      <BLOCKQUOTE 
      style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: blue 2px solid"><FONT 
        style="BACKGROUND-COLOR: transparent" color=#000000 size=2 
        face=Arial>[This e-mail contains a MIME (Multipurpose Internet Mail 
        Extensions) file. The file was specially formatted to be sent over the 
        Internet. For more information on opening the attached file, go to 
        Keyword: 
MIME.]</FONT></BLOCKQUOTE></DIV></FONT></DIV></DIV></TD></TR></TBODY></TABLE></DIV></BODY></HTML>
--part1_68c4a.3e3e6051.3f204fee_boundary--

From: Xuxiaohu <[email-masked]>
To: Peter Psenak <[email-masked]>
Date: Tue, 23 Jul 2013 09:37:27 +0000
Accept-Language: zh-CN, en-US
Cc: "[email-masked]" <[email-masked]>
Subject: [Status] =?utf-8?b?562U5aSNOiDnrZTlpI06ICBmd2Q6IE5ldyBWZXJzaW9u?= =?utf-8?q?_Notification_for_draft-xu-rtgwg-global-label-adv-00.txt?X-BeenThere: [email-masked]

Date: Tue, 23 Jul 2013 09:02:21 +0200
From: Peter Psenak <[email-masked]>
To: Xuxiaohu <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] =?utf-8?b?562U5aSNOiAgZndkOiBOZXcgVmVyc2lvbiBOb3RpZmlj?= =?utf-8?q?ation_for_draft-xu-rtgwg-global-label-adv-00.txt?X-BeenThere: [email-masked]

Xuxiaohu,

On 7/23/13 03:06 , Xuxiaohu wrote:

>>>
>>> As you pointed out, the flooding scope of the OSPFv2 Extended Prefix Opaque
>> DEPENDS on the content inside the LSA in the SR draft. However, In my draft,
>> the flooding scope of the OSPFv2 Prefix Opaque LSA DOESN'T DEPEND on the
>> content inside the LSA.
>>
>> given that OSPFv2 Extended Prefix Opaque LSA as defined in existing OSPF
>> SR draft allows you to do what you need, there is no need to define a
>> new LSA.
>
> The major difference lies in the TLVs and sub-TLVs contained in that prefix specific opaque LSA rather than the opaque LSA itself which only needs a Opaque type code to be assigned.

then you should reuse the LSA as defined in the current SR draft.

thanks,
Peter

>
> Best regards,
> Xiaohu
>
>> regards,
>> Peter
>>
>>>
>>> Best regards,
>>> Xiaohu
>>>
>
>
>

From: Xuxiaohu <[email-masked]>
To: Peter Psenak <[email-masked]>
Date: Tue, 23 Jul 2013 01:06:22 +0000
Accept-Language: zh-CN, en-US
Cc: "[email-masked]" <[email-masked]>
Subject: [Status] =?utf-8?b?562U5aSNOiAgZndkOiBOZXcgVmVyc2lvbiBOb3RpZmlj?= =?utf-8?q?ation_for_draft-xu-rtgwg-global-label-adv-00.txt?X-BeenThere: [email-masked]

From: [email-masked]
Full-name: texaswritworks
Date: Mon, 22 Jul 2013 17:55:44 -0400 (EDT)
To: [email-masked]
X-AOL-SCOLL-URL_COUNT: 0  
x-aol-sid: 3039ac1d294b51edaa604067
Subject: Re: [Status] status Digest, Vol 2, Issue 10
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <status.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/status>, <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/status>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/status>, <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Mon, 22 Jul 2013 21:55:58 -0000

--part1_a64b1.1f44c5ea.3f1f0460_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

 
I attempted to open this file with Wise Convert, but was unable to do  so 
due to unknown extension. I went to keyword MIME and was referred to  Wise 
Convert. Any suggestions? Please excuse my ignorance as I am a novice  eager 
to learn.
 
David C. Bolton

Certified  Paralegal
Texas Writ Works
6804-E Hwy 6 South #525
Houston, Texas  77083
(832) 794-3787
Fax: (281)  277-8374
[email-masked]

DISCLAIMER: Texas Writ Works is  a pro se document research and preparation 
service only. We are not  attorneys and do not hire attorneys. TWW will not 
engage in the  unauthorized practice of law. TWW will refer you to an 
attorney upon  written request.  

In a message dated 7/22/2013 2:01:27 P.M. Central Daylight Time,  
[email-masked] writes:

[This e-mail contains a MIME (Multipurpose Internet Mail  Extensions) file. 
The file was specially formatted to be sent over the  Internet. For more 
information on opening the attached file, go to  Keyword:  MIME.]

--part1_a64b1.1f44c5ea.3f1f0460_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>AOL Email</TITLE>
<META content="text/html; charset=US-ASCII" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 10.00.9200.16635">
<META name=Stationery 
content=http://cdn-cf.aol.com/se/stationery/objts/paper-st/clouds.htm></HEAD>
<BODY style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; COLOR: #000000" bottomMargin=0 
leftMargin=0 rightMargin=0 topMargin=0>
<DIV id=role_document>
<TABLE id=role_layout height="100%" cellSpacing=0 cellPadding=7 width="100%" 
align=center 
background=http://cdn-cf.aol.com/se/stationery/objts/paper-st/paper/stationery.466-1250.clouds 
border=0>
  <TBODY>
  <TR height="100%">
    <TD width="100%">
      <DIV id=role_body 
      style="FONT-SIZE: 10pt; HEIGHT: 100%; FONT-FAMILY: Arial; COLOR: #000000">
      <DIV>I attempted to open this file with Wise Convert, but was unable to do 
      so due to unknown extension. I went to keyword MIME and was referred to 
      Wise Convert. Any suggestions? Please excuse my ignorance as I am a novice 
      eager to learn.</DIV>
      <DIV>&nbsp;</DIV>
      <DIV><FONT lang=0 size=3 face="Times New Roman TUR" FAMILY="SERIF" 
      PTSIZE="12"><B>David C. Bolton</FONT><FONT lang=0 color=#000000 size=2 
      face="Times New Roman TUR" FAMILY="SERIF" PTSIZE="10"></B><BR>Certified 
      Paralegal<BR>Texas Writ Works<BR>6804-E Hwy 6 South #525<BR>Houston, Texas 
      77083<BR>(832) 794-3787<BR>Fax: (281) 
      277-8374<BR>[email-masked]<BR><BR>DISCLAIMER: Texas Writ Works is 
      a pro se document research and preparation service only. We are not 
      attorneys and do not hire attorneys. TWW will not engage in the 
      unauthorized practice of law. TWW will refer you to an attorney upon 
      written request. 
      <DIV>&nbsp;</DIV>
      <DIV>
      <DIV>In a message dated 7/22/2013 2:01:27 P.M. Central Daylight Time, 
      [email-masked] writes:</DIV>
      <BLOCKQUOTE 
      style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: blue 2px solid"><FONT 
        style="BACKGROUND-COLOR: transparent" color=#000000 size=2 
        face=Arial>[This e-mail contains a MIME (Multipurpose Internet Mail 
        Extensions) file. The file was specially formatted to be sent over the 
        Internet. For more information on opening the attached file, go to 
        Keyword: 
MIME.]</FONT></BLOCKQUOTE></DIV></FONT></DIV></DIV></TD></TR></TBODY></TABLE></DIV></BODY></HTML>
--part1_a64b1.1f44c5ea.3f1f0460_boundary--

Date: Mon, 22 Jul 2013 13:06:50 +0200
From: Peter Psenak <[email-masked]>
To: Xuxiaohu <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] fwd: New Version Notification for draft-xu-rtgwg-global-label-adv-00.txt

Xiaohu,

On 7/22/13 05:19 , Xuxiaohu wrote:

>>
>> - nothing in existing SR drafts prevents you to advertise SIDs/labels
>> from mapping server even for prefixes connected to SR capable routers.
>
> Yes, it doesn't prevent that case explicitly. However, I haven't seen any description of that case in the existing SR drafts.

does not mean you can not do it.

>
> As you pointed out, the flooding scope of the OSPFv2 Extended Prefix Opaque DEPENDS on the content inside the LSA in the SR draft. However, In my draft, the flooding scope of the OSPFv2 Prefix Opaque LSA DOESN'T DEPEND on the content inside the LSA.

given that OSPFv2 Extended Prefix Opaque LSA as defined in existing OSPF 
SR draft allows you to do what you need, there is no need to define a 
new LSA.

regards,
Peter

>
> Best regards,
> Xiaohu
>

From: Mach Chen <[email-masked]>
To: Gregory Mirsky <[email-masked]>, "[email-masked]" <[email-masked]>
Accept-Language: en-US, zh-CN
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] [mpls] FW: New Version Notification	for	draft-chen-mpls-source-label-00.txt

Hi Greg,

Many thanks for comments and questions!

Please see my reply inline...

Best regards,
Mach

> -----Original Message-----
> From: Mach Chen
> Sent: Monday, July 22, 2013 11:05 AM
> To: Mach Chen
> Subject: FW: [mpls] FW: New Version Notification for
> draft-chen-mpls-source-label-00.txt
> 
> 
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Gregory Mirsky
> Sent: Friday, July 19, 2013 7:27 PM
> To: Mach Chen; [email-masked]
> Cc: [email-masked]
> Subject: Re: [mpls] FW: New Version Notification for
> draft-chen-mpls-source-label-00.txt
> 
> Hi Mach, authors and et. al,
> very interesting idea, please find my comments and questions below:
> . I think that you propose SL for MPLS networks that permit label merge. But
> even for such networks, as I think, we could use MEP ID TLV in OAM packets to
> identify the source. Yes, that would not help much with passive OAM but will
> work for active PM.

For PM scenario, the SL solution is mainly designed for passive PM; and technically, both the SL solution and Source MEP ID TLV can apply to active PM. The SL solution does not preclude to use MEP ID TLV in OAM packets. The SL is mainly used in service packets, it can use in OAM packets as well.

> . Since SL being defined with scope of a single administrative domain MS-PW
> example in section 1 might not be applicable as SL would not be of much help.

The draft said:
"In its function as a Source Label (ingress node identifier), it MUST be unique within a domain. In cases where a Source Label is used across domains it MUST be unique within the scope it is used."

So, it does not preclude to use SL across domains if the SL can be unique across the domains.   

> . I don't think that RFC 6374 and its LM in particular are specifically targetted
> towards passive method of PM.

If my memory is right, for LM, RFC 6374 supports both (it calls inferred and direct measurement). I think you may refer to the DM that belongs to active measurement. 

> . I don't think that PM measurement at intermeddiate LSR can be effectively
> used to avoid congested path. Consider that LSR is downstream of a congested
> segment and would need to notify the upstream LSR or LER about identified
> congestion (ECN) in order to take any action.

IMHO, there are two use cases to measure at the intermediate LSRs, one is for fault localization. 

The other is like this, hierarchy model :

LSP1  S11-------------------------D11
LSP2        S21-----D22

LSP1 is over LSP2 (there may be many LSPs over LSP2), it may need to measure and collect the traffic matrix at S21 (to measure the throughput of each LSP that is over on LSP2), then based on some conditions, it could steer some LSPs to other tunnels, or move other LSPs to this tunnel. 

Best regards,
Mach

> 
>         Regards,
>                 Greg
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Mach Chen
> Sent: Friday, July 19, 2013 2:07 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [mpls] FW: New Version Notification for
> draft-chen-mpls-source-label-00.txt
> 
> Hi MPLSers,
> 
> We just uploaded a draft that introduces a concept of MPLS Source Label (SL), the
> source label is encoded in the label stack (immediately follows a special purpose
> label ) and used to identify the ingress LSR of an LSP. The source label applies to
> the scenarios where source identification is required (e.g., in order for counting
> and billing). For example, Performance Measurement for MPLS network, Traffic
> Matrix measurement and collection, etc.
> 
> We'd appreciate that you could take a look at the draft. Any comments and
> suggestion are welcome!
> 
> BTW, I cc the STATUS list for the people who may have interest, since the
> segment routing requires to preserve the ingress to a domain for accounting and
> billing purpose, the source label can help here.
> 
> Best regards,
> Mach
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, July 15, 2013 5:58 PM
> To: Lizhenbin; Mach Chen; Xuxiaohu; Xuxiaohu; Luyuan Fang; Mach Chen
> Subject: New Version Notification for draft-chen-mpls-source-label-00.txt
> 
> 
> A new version of I-D, draft-chen-mpls-source-label-00.txt
> has been successfully submitted by Mach(Guoyi) Chen and posted to the IETF
> repository.
> 
> Filename:        draft-chen-mpls-source-label
> Revision:        00
> Title:           MultiProtocol Label Switching (MPLS) Source Label Creation
> date:   2013-07-15
> Group:           Individual Submission
> Number of pages: 12
> URL:             http://www.ietf.org/internet-drafts/draft-chen-mpls-sou
> rce-label-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-chen-mpls-source-lab
> el
> Htmlized:        http://tools.ietf.org/html/draft-chen-mpls-source-label-00
> 
> 
> Abstract:
>    An MultiProtocol Label Switching (MPLS) label is originally defined
>    to identify a Forwarding Equivalence Class (FEC), a packet is
>    assigned to a specific FEC based on its network layer destination
>    address.  It's difficult or even impossible to derive the source
>    information from the label.  For some applications, source
>    identification is a critical requirement.  For example, performance
>    monitoring, traffic matrix measurement and collection, where the
>    monitoring node needs to identify where a packet was sent from.
> 
>    This document introduces the concept of Source Label (SL) that is
>    carried in the label stack and used to identify the ingress Label
>    Switching Router (LSR) of an Label Switched Path (LSP).
> 
> 
> 
> 
> 
> The IETF Secretariat
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
> 

From: Xuxiaohu <[email-masked]>
To: Peter Psenak <[email-masked]>
Accept-Language: zh-CN, en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] fwd: New Version Notification for draft-xu-rtgwg-global-label-adv-00.txt

From: [email-masked]
Full-name: texaswritworks
Date: Sat, 20 Jul 2013 16:42:22 -0400 (EDT)
To: [email-masked]
X-AOL-SCOLL-URL_COUNT: 0  
x-aol-sid: 3039ac1d294a51eaf62e5ae1
Subject: Re: [Status] status Digest, Vol 2, Issue 8
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <status.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/status>, <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/status>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/status>, <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Sat, 20 Jul 2013 20:42:33 -0000

--part1_b3e56.26343eaf.3f1c502e_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

 
Thank you, I would certainly like to be able to obtain a copy of STD  11, 
RFC 822 & 1049, if at all possible.
 
Thank you again!
 
Sincerely,
 
David C. Bolton

Certified  Paralegal
Texas Writ Works
6804-E Hwy 6 South #525
Houston, Texas  77083
(832) 794-3787
Fax: (281)  277-8374
[email-masked]

DISCLAIMER: Texas Writ Works is  a pro se document research and preparation 
service only. We are not  attorneys and do not hire attorneys. TWW will not 
engage in the  unauthorized practice of law. TWW will refer you to an 
attorney upon  written request.  

In a message dated 7/20/2013 2:01:20 P.M. Central Daylight Time,  
[email-masked] writes:

[This e-mail contains a MIME (Multipurpose Internet Mail  Extensions) file. 
The file was specially formatted to be sent over the  Internet. For more 
information on opening the attached file, go to  Keyword:  MIME.]

--part1_b3e56.26343eaf.3f1c502e_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>AOL Email</TITLE>
<META content="text/html; charset=US-ASCII" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 10.00.9200.16635">
<META name=Stationery 
content=http://cdn-cf.aol.com/se/stationery/objts/paper-st/clouds.htm></HEAD>
<BODY style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; COLOR: #000000" bottomMargin=0 
leftMargin=0 rightMargin=0 topMargin=0>
<DIV id=role_document>
<TABLE id=role_layout height="100%" cellSpacing=0 cellPadding=7 width="100%" 
align=center 
background=http://cdn-cf.aol.com/se/stationery/objts/paper-st/paper/stationery.466-1250.clouds 
border=0>
  <TBODY>
  <TR height="100%">
    <TD width="100%">
      <DIV id=role_body 
      style="FONT-SIZE: 10pt; HEIGHT: 100%; FONT-FAMILY: Arial; COLOR: #000000">
      <DIV>Thank you, I would certainly like to be able to obtain a copy of STD 
      11, RFC 822 &amp; 1049, if at all possible.</DIV>
      <DIV>&nbsp;</DIV>
      <DIV>Thank you again!</DIV>
      <DIV>&nbsp;</DIV>
      <DIV>Sincerely,</DIV>
      <DIV>&nbsp;</DIV>
      <DIV><FONT lang=0 size=3 face="Times New Roman TUR" FAMILY="SERIF" 
      PTSIZE="12"><B>David C. Bolton</FONT><FONT lang=0 color=#000000 size=2 
      face="Times New Roman TUR" FAMILY="SERIF" PTSIZE="10"></B><BR>Certified 
      Paralegal<BR>Texas Writ Works<BR>6804-E Hwy 6 South #525<BR>Houston, Texas 
      77083<BR>(832) 794-3787<BR>Fax: (281) 
      277-8374<BR>[email-masked]<BR><BR>DISCLAIMER: Texas Writ Works is 
      a pro se document research and preparation service only. We are not 
      attorneys and do not hire attorneys. TWW will not engage in the 
      unauthorized practice of law. TWW will refer you to an attorney upon 
      written request. 
      <DIV>&nbsp;</DIV>
      <DIV>
      <DIV>In a message dated 7/20/2013 2:01:20 P.M. Central Daylight Time, 
      [email-masked] writes:</DIV>
      <BLOCKQUOTE 
      style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: blue 2px solid"><FONT 
        style="BACKGROUND-COLOR: transparent" color=#000000 size=2 
        face=Arial>[This e-mail contains a MIME (Multipurpose Internet Mail 
        Extensions) file. The file was specially formatted to be sent over the 
        Internet. For more information on opening the attached file, go to 
        Keyword: 
MIME.]</FONT></BLOCKQUOTE></DIV></FONT></DIV></DIV></TD></TR></TBODY></TABLE></DIV></BODY></HTML>
--part1_b3e56.26343eaf.3f1c502e_boundary--

Date: Sat, 20 Jul 2013 10:36:50 +0300
From: Saku Ytti <[email-masked]>
To: "[email-masked]" <[email-masked]>, [email-masked], "John G. Scudder" <[email-masked]>
Subject: Re: [Status] stacked tunnels BOF

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

5min should suffice. My use case is about reduced complexity in our network
while increasing functionality.

On 18 July 2013 18:59, Saku Ytti <[email-masked]> wrote:

> https://datatracker.ietf.org/meeting/87/agenda/status/
>
> Could I get 10min use-case slot?
>
> Saku Ytti <[email-masked]>, TDC
>
> Thanks,
> --
>   ++ytti
>

-- 
  ++ytti

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

<div dir="ltr">5min should suffice. My use case is about reduced complexity in our network while increasing functionality.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On 18 July 2013 18:59, Saku Ytti <span dir="ltr">&lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><a href="https://datatracker.ietf.org/meeting/87/agenda/status/" target="_blank">https://datatracker.ietf.org/meeting/87/agenda/status/</a><div>
<br></div><div>Could I get 10min use-case slot?</div><div><br></div><div>Saku Ytti &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;, TDCÂ <br clear="all">
<div><br></div><div>Thanks,</div><span class="HOEnZb"><font color="#888888">-- <br>Â  ++ytti
</font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Â  ++ytti
</div>

--e89a8ff1cab49f803f04e1ec817e--

From: Gregory Mirsky <[email-masked]>
To: Mach Chen <[email-masked]>, "[email-masked]" <[email-masked]>
Accept-Language: en-US
Subject: Re: [Status] [mpls] FW: New Version Notification for	draft-chen-mpls-source-label-00.txt

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

Hi Mach, authors and et. al,
very interesting idea, please find my comments and questions below:
*       I think that you propose SL for MPLS networks that permit label merge. But even for such networks, as I think, we could use MEP ID TLV in OAM packets to identify the source. Yes, that would not help much with passive OAM but will work for active PM.
   *    Since SL being defined with scope of a single administrative domain MS-PW example in section 1 might not be applicable as SL would not be of much help.
   *    I don't think that RFC 6374 and its LM in particular are specifically targetted towards passive method of PM.
   *    I don't think that PM measurement at intermeddiate LSR can be effectively used to avoid congested path. Consider that LSR is downstream of a congested segment and would need to notify the upstream LSR or LER about identified congestion (ECN) in order to take any action.

        Regards,
                Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mach Chen
Sent: Friday, July 19, 2013 2:07 AM
To: [email-masked]
Cc: [email-masked]
Subject: [mpls] FW: New Version Notification for draft-chen-mpls-source-label-00.txt

Hi MPLSers,

We just uploaded a draft that introduces a concept of MPLS Source Label (SL), the source label is encoded in the label stack (immediately follows a special purpose label ) and used to identify the ingress LSR of an LSP. The source label applies to the scenarios where source identification is required (e.g., in order for counting and billing). For example, Performance Measurement for MPLS network, Traffic Matrix measurement and collection, etc.

We'd appreciate that you could take a look at the draft. Any comments and suggestion are welcome!

BTW, I cc the STATUS list for the people who may have interest, since the segment routing requires to preserve the ingress to a domain for accounting and billing purpose, the source label can help here.

Best regards,
Mach

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, July 15, 2013 5:58 PM
To: Lizhenbin; Mach Chen; Xuxiaohu; Xuxiaohu; Luyuan Fang; Mach Chen
Subject: New Version Notification for draft-chen-mpls-source-label-00.txt

A new version of I-D, draft-chen-mpls-source-label-00.txt
has been successfully submitted by Mach(Guoyi) Chen and posted to the
IETF repository.

Filename:        draft-chen-mpls-source-label
Revision:        00
Title:           MultiProtocol Label Switching (MPLS) Source Label
Creation date:   2013-07-15
Group:           Individual Submission
Number of pages: 12
URL:             http://www.ietf.org/internet-drafts/draft-chen-mpls-source-label-00.txt
Status:          http://datatracker.ietf.org/doc/draft-chen-mpls-source-label
Htmlized:        http://tools.ietf.org/html/draft-chen-mpls-source-label-00

Abstract:
   An MultiProtocol Label Switching (MPLS) label is originally defined
   to identify a Forwarding Equivalence Class (FEC), a packet is
   assigned to a specific FEC based on its network layer destination
   address.  It's difficult or even impossible to derive the source
   information from the label.  For some applications, source
   identification is a critical requirement.  For example, performance
   monitoring, traffic matrix measurement and collection, where the
   monitoring node needs to identify where a packet was sent from.

   This document introduces the concept of Source Label (SL) that is
   carried in the label stack and used to identify the ingress Label
   Switching Router (LSR) of an Label Switched Path (LSP).

The IETF Secretariat

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

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

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<font face="Arial" size="2"><span style="font-size:10pt;">
<div>Hi Mach, authors and et. al,</div>
<div>very interesting idea, please find my comments and questions below:</div>
<ul style="margin:0;padding-left:19pt;">
<li>I think that you propose SL for MPLS networks that permit label merge. But even for such networks, as I think, we could use MEP ID TLV in OAM packets to identify the source. Yes, that would not help much with passive OAM but will work for active PM.</li><li>Since SL being defined with scope of a single administrative domain MS-PW example in section 1 might not be applicable as SL would not be of much help.</li><li>I don't think that RFC 6374 and its LM in particular are specifically targetted towards passive method of PM.</li><li>I don't think that PM measurement at intermeddiate LSR can be effectively used to avoid congested path. Consider that LSR is downstream of a congested segment and would need to notify the upstream LSR or LER about identified congestion (ECN) in order to
take any action.</li></ul>
<div>&nbsp;</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Regards,</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Greg</div>
<div>&nbsp;</div>
<div>-----Original Message-----</div>
<div>From: [email-masked] [<a href="mailto:[email-masked]"><font color="blue"><u>mailto:[email-masked]</u></font></a>] On Behalf Of Mach Chen</div>
<div>Sent: Friday, July 19, 2013 2:07 AM</div>
<div>To: [email-masked]</div>
<div>Cc: [email-masked]</div>
<div>Subject: [mpls] FW: New Version Notification for draft-chen-mpls-source-label-00.txt</div>
<div>&nbsp;</div>
<div>Hi MPLSers,</div>
<div>&nbsp;</div>
<div>We just uploaded a draft that introduces a concept of MPLS Source Label (SL), the source label is encoded in the label stack (immediately follows a special purpose label ) and used to identify the ingress LSR of an LSP. The source label applies to the
scenarios where source identification is required (e.g., in order for counting and billing). For example, Performance Measurement for MPLS network, Traffic Matrix measurement and collection, etc.</div>
<div>&nbsp;</div>
<div>We'd appreciate that you could take a look at the draft. Any comments and suggestion are welcome!</div>
<div>&nbsp;</div>
<div>BTW, I cc the STATUS list for the people who may have interest, since the segment routing requires to preserve the ingress to a domain for accounting and billing purpose, the source label can help here. </div>
<div>&nbsp;</div>
<div>Best regards,</div>
<div>Mach</div>
<div>&nbsp;</div>
<div>-----Original Message-----</div>
<div>From: [email-masked] [<a href="mailto:[email-masked]"><font color="blue"><u>mailto:[email-masked]</u></font></a>]</div>
<div>Sent: Monday, July 15, 2013 5:58 PM</div>
<div>To: Lizhenbin; Mach Chen; Xuxiaohu; Xuxiaohu; Luyuan Fang; Mach Chen</div>
<div>Subject: New Version Notification for draft-chen-mpls-source-label-00.txt</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>A new version of I-D, draft-chen-mpls-source-label-00.txt</div>
<div>has been successfully submitted by Mach(Guoyi) Chen and posted to the</div>
<div>IETF repository.</div>
<div>&nbsp;</div>
<div>Filename:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; draft-chen-mpls-source-label</div>
<div>Revision:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 00</div>
<div>Title:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MultiProtocol Label Switching (MPLS) Source Label</div>
<div>Creation date:&nbsp;&nbsp; 2013-07-15</div>
<div>Group:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Individual Submission</div>
<div>Number of pages: 12</div>
<div>URL:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://www.ietf.org/internet-drafts/draft-chen-mpls-source-label-00.txt"><font color="blue"><u>http://www.ietf.org/internet-drafts/draft-chen-mpls-source-label-00.txt</u></font></a></div>
<div>Status:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://datatracker.ietf.org/doc/draft-chen-mpls-source-label"><font color="blue"><u>http://datatracker.ietf.org/doc/draft-chen-mpls-source-label</u></font></a></div>
<div>Htmlized:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://tools.ietf.org/html/draft-chen-mpls-source-label-00"><font color="blue"><u>http://tools.ietf.org/html/draft-chen-mpls-source-label-00</u></font></a></div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>Abstract:</div>
<div>&nbsp;&nbsp; An MultiProtocol Label Switching (MPLS) label is originally defined</div>
<div>&nbsp;&nbsp; to identify a Forwarding Equivalence Class (FEC), a packet is</div>
<div>&nbsp;&nbsp; assigned to a specific FEC based on its network layer destination</div>
<div>&nbsp;&nbsp; address.&nbsp; It's difficult or even impossible to derive the source</div>
<div>&nbsp;&nbsp; information from the label.&nbsp; For some applications, source</div>
<div>&nbsp;&nbsp; identification is a critical requirement.&nbsp; For example, performance</div>
<div>&nbsp;&nbsp; monitoring, traffic matrix measurement and collection, where the</div>
<div>&nbsp;&nbsp; monitoring node needs to identify where a packet was sent from.</div>
<div>&nbsp;</div>
<div>&nbsp;&nbsp; This document introduces the concept of Source Label (SL) that is</div>
<div>&nbsp;&nbsp; carried in the label stack and used to identify the ingress Label</div>
<div>&nbsp;&nbsp; Switching Router (LSR) of an Label Switched Path (LSP).</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>The IETF Secretariat</div>
<div>&nbsp;</div>
<div>_______________________________________________</div>
<div>mpls mailing list</div>
<div>[email-masked]</div>
<div><a href="https://www.ietf.org/mailman/listinfo/mpls"><font color="blue"><u>https://www.ietf.org/mailman/listinfo/mpls</u></font></a></div>
<div>&nbsp;</div>
</span></font>
</body>
</html>

--_000_7347100B5761DC41A166AC17F22DF1121B6A0122eusaamb103erics_--

Date: Fri, 19 Jul 2013 12:13:02 +0200
From: Peter Psenak <[email-masked]>
To: Xuxiaohu <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] fwd: New Version Notification for draft-xu-rtgwg-global-label-adv-00.txt

Xiaohu

On 7/19/13 12:00 , Xuxiaohu wrote:
> Hi Peter,
>
>> -----é‚®ä»¶åŽŸä»¶-----
>> å‘ä»¶äºº: Peter Psenak [mailto:[email-masked]]
>> å‘é€æ—¶é—´: 2013å¹´7æœˆ19æ—¥ 17:01
>> æ”¶ä»¶äºº: Xuxiaohu
>> æŠ„é€: [email-masked]
>> ä¸»é¢˜: Re: [Status] fwd: New Version Notification for
>> draft-xu-rtgwg-global-label-adv-00.txt
>>
>> Xiaohu,
>>
>> I do not see anything new in your draft.
>>
>> 1. Mapping Server functionality is described in SR use case draft
>> (draft-filsfils-rtgwg-segment-routing-use-cases-00)
>
> If I understand the mapping server functionality described in the current SR drafts correctly, the mapping server is only used for advertising prefix segments on behalf of non-SR-capable routers. See the following quoted text from the SR use case draft:
>
> "  The mappings advertised by an SR mapping server result from local
>     policy information configured by the operator.  IF PE3 had been SR
>     capable, the operator would have configured PE3 with node segment
>     103.  Instead, as PE3 is not SR capable, the operator configures that
>     policy at the SRMS and it is the latter which advertises the mapping."
>
> In my draft, all the global labels for prefixes (i.e., prefix segments or node segments called in SR) should be allocated and advertised by the mapping server, rather than by any SR-capable routers. In the way, there is no risk of label allocation collision. SR-capable routers just need to allocated and advertise local labels for adjacencies (i.e., adjacency segments) . Furthermore, those prefixes which need to be allocated with global labels can be manually configured on the mapping servers or be advertised by the corresponding SR-capable by using the Label-request sub-TLVs.

- nothing in existing SR drafts prevents you to advertise SIDs/labels 
from mapping server even for prefixes connected to SR capable routers.

- current SR drafts already defined a way to advertise SID/label, I do 
not see why Label-request sub-TLVs is any different.

>
>> 2. existing OSPF/ISIS SR drafts have already defined label-binding TLV
>> and Extended Prefix Opaque LSA has been defined in OSPF SR draft.
>
>
> Besides, the approach defined in the current SR drafts requires additional work on the ABRs to deal with the label advertisement when reachability information is propagated across areas, see the following quoted text from the SR OSPF extension draft:
>
> " When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area
>     route to all its connected areas it will also originate an Extended
>     Prefix Opaque LSA, as described in Section 4.  The flooding scope of
>     the Extended Prefix Opaque LSA type will be set to area-scope.  The
>     route-type in OSPF Extended Prefix TLV is set to inter-area.  The
>     Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID
>     will be set as follows:"
>
> In my draft, since the Opaque Prefix LSAs containing either the label-request sub-TLV or the label-binding sub-TLV be flooded within the domain scope, there is no complex work required on the ABRs.

current OSPF SR draft does not prevent you to use domain-wide flooding 
if that is what you need:

"Flooding scope of the OSPFv2 Extended Prefix Opaque
  LSA depends on the content inside the LSA and is in control of the
  originating router."

>
>> 3. Multiple Mapping Servers can advertise labels, there is no need to do
>> any election.
>
> The reason for the mapping server election is to avoid the risk of label allocation collision between multiple mapping servers.
>
> Anyway, differences lie in details.

right and too many details are too close to existing SR drafts.

regards,
Peter

>
> Best regards,
> Xiaohu
>
>> regards,
>> Peter
>>
>>
>>
>>
>> On 7/19/13 09:31 , Xuxiaohu wrote:
>>> Hi all,
>>>
>>> This draft proposes a new way to advertise global labels without any risk of
>> label collision. Any comments are welcome.
>>>
>>> Br,
>>> Xiaohu
>>>
>>>> -----é‚®ä»¶åŽŸä»¶-----
>>>> å‘ä»¶äºº: [email-masked] [mailto:[email-masked]]
>>>> å‘é€æ—¶é—´: 2013å¹´7æœˆ11æ—¥ 16:18
>>>> æ”¶ä»¶äºº: Mach Chen; Mach Chen; Xuxiaohu; Xuxiaohu
>>>> ä¸»é¢˜: New Version Notification for draft-xu-rtgwg-global-label-adv-00.txt
>>>>
>>>>
>>>> A new version of I-D, draft-xu-rtgwg-global-label-adv-00.txt
>>>> has been successfully submitted by Xiaohu Xu and posted to the
>>>> IETF repository.
>>>>
>>>> Filename:	 draft-xu-rtgwg-global-label-adv
>>>> Revision:	 00
>>>> Title:		 Advertising Global Labels Using IGP
>>>> Creation date:	 2013-07-11
>>>> Group:		 Individual Submission
>>>> Number of pages: 9
>>>> URL:
>>>> http://www.ietf.org/internet-drafts/draft-xu-rtgwg-global-label-adv-00.txt
>>>> Status:
>>>> http://datatracker.ietf.org/doc/draft-xu-rtgwg-global-label-adv
>>>> Htmlized:
>>>> http://tools.ietf.org/html/draft-xu-rtgwg-global-label-adv-00
>>>>
>>>>
>>>> Abstract:
>>>>      Segment Routing (SR) [SR-ARCH] is a new MPLS paradigm in which
>> each
>>>>      SR-capable router is required to independently advertise global MPLS
>>>>      labels for its attached prefixes using IGP [SR-ISIS-EXT][SR-OSPF-EXT].
>>>>      One major challenge associated with such label advertisement
>>>>      mechanism is how to avoid a given global MPLS label from being
>>>>      allocated by different routers to different prefixes. Although manual
>>>>      allocation can address such label allocation collision problem, it is
>>>>      error-prone and therefore may not be suitable for large SR network
>>>>      environments. This document proposes an alternative approach for
>>>>      advertising global labels without any risk of label allocation
>>>>      collision.
>>>>
>>>>
>>>>
>>>>
>>>> The IETF Secretariat
>>>
>>> _______________________________________________
>>> 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: Xuxiaohu <[email-masked]>
To: Peter Psenak <[email-masked]>
Date: Fri, 19 Jul 2013 10:00:24 +0000
Accept-Language: zh-CN, en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] fwd: New Version Notification for draft-xu-rtgwg-global-label-adv-00.txt

From: Mach Chen <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 19 Jul 2013 09:06:39 +0000
Accept-Language: en-US, zh-CN
Cc: "[email-masked]" <[email-masked]>
Subject: [Status] FW: New Version Notification for draft-chen-mpls-source-label-00.txt

Date: Fri, 19 Jul 2013 11:01:13 +0200
From: Peter Psenak <[email-masked]>
To: Xuxiaohu <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] fwd: New Version Notification for draft-xu-rtgwg-global-label-adv-00.txt

Xiaohu,

I do not see anything new in your draft.

1. Mapping Server functionality is described in SR use case draft 
(draft-filsfils-rtgwg-segment-routing-use-cases-00)

2. existing OSPF/ISIS SR drafts have already defined label-binding TLV 
and Extended Prefix Opaque LSA has been defined in OSPF SR draft.

3. Multiple Mapping Servers can advertise labels, there is no need to do 
any election.

regards,
Peter

On 7/19/13 09:31 , Xuxiaohu wrote:
> Hi all,
>
> This draft proposes a new way to advertise global labels without any risk of label collision. Any comments are welcome.
>
> Br,
> Xiaohu
>
>> -----é‚®ä»¶åŽŸä»¶-----
>> å‘ä»¶äºº: [email-masked] [mailto:[email-masked]]
>> å‘é€æ—¶é—´: 2013å¹´7æœˆ11æ—¥ 16:18
>> æ”¶ä»¶äºº: Mach Chen; Mach Chen; Xuxiaohu; Xuxiaohu
>> ä¸»é¢˜: New Version Notification for draft-xu-rtgwg-global-label-adv-00.txt
>>
>>
>> A new version of I-D, draft-xu-rtgwg-global-label-adv-00.txt
>> has been successfully submitted by Xiaohu Xu and posted to the
>> IETF repository.
>>
>> Filename:	 draft-xu-rtgwg-global-label-adv
>> Revision:	 00
>> Title:		 Advertising Global Labels Using IGP
>> Creation date:	 2013-07-11
>> Group:		 Individual Submission
>> Number of pages: 9
>> URL:
>> http://www.ietf.org/internet-drafts/draft-xu-rtgwg-global-label-adv-00.txt
>> Status:
>> http://datatracker.ietf.org/doc/draft-xu-rtgwg-global-label-adv
>> Htmlized:
>> http://tools.ietf.org/html/draft-xu-rtgwg-global-label-adv-00
>>
>>
>> Abstract:
>>     Segment Routing (SR) [SR-ARCH] is a new MPLS paradigm in which each
>>     SR-capable router is required to independently advertise global MPLS
>>     labels for its attached prefixes using IGP [SR-ISIS-EXT][SR-OSPF-EXT].
>>     One major challenge associated with such label advertisement
>>     mechanism is how to avoid a given global MPLS label from being
>>     allocated by different routers to different prefixes. Although manual
>>     allocation can address such label allocation collision problem, it is
>>     error-prone and therefore may not be suitable for large SR network
>>     environments. This document proposes an alternative approach for
>>     advertising global labels without any risk of label allocation
>>     collision.
>>
>>
>>
>>
>> The IETF Secretariat
>
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>
>

Date: Fri, 19 Jul 2013 11:41:45 +0300
From: Saku Ytti <[email-masked]>
To: Xuxiaohu <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Status] fwd: New Version Notification for draft-xu-rtgwg-global-label-adv-00.txt

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

Hi Xiaohu,

If I understand correctly there are two unique obstacles why different
people oppose global labels

1. need for unique ID/label per node
       - your draft clearly solves this
       - but is this really a problem? Operators handle NET/CLNS/IPv4/IPv6
uniqueness today, so it's ingrained process?
       - I personally greatly favor local/static config to
signalling/states, less things to break

2. need for globally agreed block
       - every application of every device must have 'hole' in their label
manager for this block, so no other application tries to allocate label
from this block
       - as I see it, in your proposal this demand still remains, that is
if mapping server proposes that I use label 42, which I've already assigned
for another application, things break?
       - essentially solution would be to implement such guarantee which is
additional upgrade-cycle

I personally can accept both requirement and live with them. But I know
there are people who say 2. is show stopper and such requirement cannot
exist. 1. seem far less opposed.

Operationally I'm quite worried about the added external requirements for
my local forwarding, but this might be just rush reaction to new idea.

On 19 July 2013 10:31, Xuxiaohu <[email-masked]> wrote:

> Hi all,
>
> This draft proposes a new way to advertise global labels without any risk
> of label collision. Any comments are welcome.
>
> Br,
> Xiaohu
>
> > -----é‚®ä»¶åŽŸä»¶-----
> > å‘ä»¶äºº: [email-masked] [mailto:[email-masked]]
> > å‘é€æ—¶é—´: 2013å¹´7æœˆ11æ—¥ 16:18
> > æ”¶ä»¶äºº: Mach Chen; Mach Chen; Xuxiaohu; Xuxiaohu
> > ä¸»é¢˜: New Version Notification for draft-xu-rtgwg-global-label-adv-00.txt
> >
> >
> > A new version of I-D, draft-xu-rtgwg-global-label-adv-00.txt
> > has been successfully submitted by Xiaohu Xu and posted to the
> > IETF repository.
> >
> > Filename:      draft-xu-rtgwg-global-label-adv
> > Revision:      00
> > Title:                 Advertising Global Labels Using IGP
> > Creation date:         2013-07-11
> > Group:                 Individual Submission
> > Number of pages: 9
> > URL:
> >
> http://www.ietf.org/internet-drafts/draft-xu-rtgwg-global-label-adv-00.txt
> > Status:
> > http://datatracker.ietf.org/doc/draft-xu-rtgwg-global-label-adv
> > Htmlized:
> > http://tools.ietf.org/html/draft-xu-rtgwg-global-label-adv-00
> >
> >
> > Abstract:
> >    Segment Routing (SR) [SR-ARCH] is a new MPLS paradigm in which each
> >    SR-capable router is required to independently advertise global MPLS
> >    labels for its attached prefixes using IGP [SR-ISIS-EXT][SR-OSPF-EXT].
> >    One major challenge associated with such label advertisement
> >    mechanism is how to avoid a given global MPLS label from being
> >    allocated by different routers to different prefixes. Although manual
> >    allocation can address such label allocation collision problem, it is
> >    error-prone and therefore may not be suitable for large SR network
> >    environments. This document proposes an alternative approach for
> >    advertising global labels without any risk of label allocation
> >    collision.
> >
> >
> >
> >
> > The IETF Secretariat
>
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>

-- 
  ++ytti

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

<div dir="ltr">HiÂ Xiaohu,<div><br></div><div>If I understand correctly there are two unique obstacles why different people oppose global labels<br></div><div><br></div><div>1. need for unique ID/label per node</div><div>Â  Â  Â  Â - your draft clearly solves this</div>
<div>Â  Â  Â  Â - but is this really a problem? Operators handle NET/CLNS/IPv4/IPv6 uniqueness today, so it&#39;s ingrained process?</div><div>Â  Â  Â  Â - I personally greatly favor local/static config to signalling/states, less things to break</div>
<div><br></div><div>2. need for globally agreed block</div><div>Â  Â  Â  Â - every application of every device must have &#39;hole&#39; in their label manager for this block, so no other application tries to allocate label from this block</div>
<div>Â  Â  Â  Â - as I see it, in your proposal this demand still remains, that is if mapping server proposes that I use label 42, which I&#39;ve already assigned for another application, things break?</div><div>Â  Â  Â  Â - essentially solution would be to implement such guarantee which is additional upgrade-cycle</div>
<div><br></div><div>I personally can accept both requirement and live with them. But I know there are people who say 2. is show stopper and such requirement cannot exist. 1. seem far less opposed.</div><div><br></div><div>
Operationally I&#39;m quite worried about the added external requirements for my local forwarding, but this might be just rush reaction to new idea.</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On 19 July 2013 10:31, Xuxiaohu <span dir="ltr">&lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
This draft proposes a new way to advertise global labels without any risk of label collision. Any comments are welcome.<br>
<br>
Br,<br>
Xiaohu<br>
<br>
&gt; -----é‚®ä»¶åŽŸä»¶-----<br>
&gt; å‘ä»¶äºº: <a href="mailto:[email-masked]">[email-masked]</a> [mailto:<a href="mailto:[email-masked]">[email-masked]</a>]<br>
&gt; å‘é€æ—¶é—´: 2013å¹´7æœˆ11æ—¥ 16:18<br>
&gt; æ”¶ä»¶äºº: Mach Chen; Mach Chen; Xuxiaohu; Xuxiaohu<br>
&gt; ä¸»é¢˜: New Version Notification for draft-xu-rtgwg-global-label-adv-00.txt<br>
&gt;<br>
&gt;<br>
&gt; A new version of I-D, draft-xu-rtgwg-global-label-adv-00.txt<br>
&gt; has been successfully submitted by Xiaohu Xu and posted to the<br>
&gt; IETF repository.<br>
&gt;<br>
&gt; Filename: Â  Â  Â draft-xu-rtgwg-global-label-adv<br>
&gt; Revision: Â  Â  Â 00<br>
&gt; Title: Â  Â  Â  Â  Â  Â  Â  Â  Advertising Global Labels Using IGP<br>
&gt; Creation date: Â  Â  Â  Â  2013-07-11<br>
&gt; Group: Â  Â  Â  Â  Â  Â  Â  Â  Individual Submission<br>
&gt; Number of pages: 9<br>
&gt; URL:<br>
&gt; <a href="http://www.ietf.org/internet-drafts/draft-xu-rtgwg-global-label-adv-00.txt" target="_blank">http://www.ietf.org/internet-drafts/draft-xu-rtgwg-global-label-adv-00.txt</a><br>
&gt; Status:<br>
&gt; <a href="http://datatracker.ietf.org/doc/draft-xu-rtgwg-global-label-adv" target="_blank">http://datatracker.ietf.org/doc/draft-xu-rtgwg-global-label-adv</a><br>
&gt; Htmlized:<br>
&gt; <a href="http://tools.ietf.org/html/draft-xu-rtgwg-global-label-adv-00" target="_blank">http://tools.ietf.org/html/draft-xu-rtgwg-global-label-adv-00</a><br>
&gt;<br>
&gt;<br>
&gt; Abstract:<br>
&gt; Â  Â Segment Routing (SR) [SR-ARCH] is a new MPLS paradigm in which each<br>
&gt; Â  Â SR-capable router is required to independently advertise global MPLS<br>
&gt; Â  Â labels for its attached prefixes using IGP [SR-ISIS-EXT][SR-OSPF-EXT].<br>
&gt; Â  Â One major challenge associated with such label advertisement<br>
&gt; Â  Â mechanism is how to avoid a given global MPLS label from being<br>
&gt; Â  Â allocated by different routers to different prefixes. Although manual<br>
&gt; Â  Â allocation can address such label allocation collision problem, it is<br>
&gt; Â  Â error-prone and therefore may not be suitable for large SR network<br>
&gt; Â  Â environments. This document proposes an alternative approach for<br>
&gt; Â  Â advertising global labels without any risk of label allocation<br>
&gt; Â  Â collision.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; The IETF Secretariat<br>
<br>
_______________________________________________<br>
status mailing list<br>
<a href="mailto:[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/status" target="_blank">https://www.ietf.org/mailman/listinfo/status</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Â  ++ytti
</div>

--e89a8ff1cab4feb03104e1d94b9c--

From: Xuxiaohu <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 19 Jul 2013 07:31:54 +0000
Accept-Language: zh-CN, en-US
Subject: [Status] fwd: New Version Notification for draft-xu-rtgwg-global-label-adv-00.txt

From: John Scudder <[email-masked]>
Date: Wed, 17 Jul 2013 16:21:25 +0300
To: "[email-masked]" <[email-masked]>
Subject: [Status] STATUS agenda uploaded

The tentative STATUS agenda has been uploaded: http://www.ietf.org/proceedings/87/agenda/agenda-87-status

If you requested agenda time and weren't turned down, please check your slot and send any corrections to the chairs. No presenter received more time than the minimum he requested. In some cases we allocated less than that, sorry. You should expect you will NOT be allowed to run over time, although note there is a long "open discussion" slot at the end of the meeting. For this reason, presenters should plan to keep their presentations short and to the point. "To the point" means, specifically, helping to answer one or more of the questions listed in the "BoF will seek to address the following questions" section of the BOF announcement (http://tools.ietf.org/bof/trac/). In general, a packet-header level of detail would be inappropriate.

Presenters should have their presentations to the chairs no later than noon EDT this coming Monday, June 22. Those who haven't sent in slides by then may lose their slot! There are others who want your time. Also, please make sure your slides have page numbers so that remote listeners can keep track.

Those planning to attend the BOF should also note that we will start at 13:00 sharp so plan your lunch accordingly. 

Finally, we would very much appreciate help with note-taking and Jabber scribing. Please volunteer your services in exchange for the undying gratitude of your peers. Note-takers may elect to cover only part of the meeting (please tell us what part you can't cover). The Jabber scribe needs to update the Jabber room with information such as what slide is being projected and (most important) to convey questions from the Jabber room to the mic during Q/A. A running transcript to Jabber is not needed.

Thanks,

--John

From: AshwoodsmithPeter <[email-masked]>
To: "[email-masked]" <[email-masked]>, SDN IRTF list <[email-masked]>
Date: Wed, 3 Jul 2013 15:31:34 +0000
Accept-Language: en-US, zh-CN
Subject: [Status] SDN state reduction with Source Routing - draft-ashwood-sdnrg-state-reduction-00.txt

FYI - relevant to STATUS and SDN IRTF.

Cheers,

Peter

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : SDN State Reduction
	Author(s)       : Peter Ashwood-Smith
                          Mourad Soliman
                          Tao Wan
	Filename        :	Pages           : 23
	Date            : 2013-07-03

Abstract:
   This document makes the argument that to support the centralized
   control of a substantial number of forwarding devices (as Software
   Defined Networking (SDN) proposes) that the scale, speed, cost and
   general quality of such a solution will be improved by reducing
   the state needed to be distributed into the network of devices by
   the controller(s). To this end we re-visit forms of Source Routing
   (SR), in particular Strict Link Source Routing (SLSR) and suggest
   that light weight SLSR could allow substantial reduction in
   controller burden while potentially reducing the costs/complexity
   on forwarding devices. We discuss some simulation results that
   demonstrate these advantages and how the advantages grow
   substantially as the network diameter grows. We also look at
   various implementation possibilities including existing IPV4, V6,
   MPLS, new/modified MPLS vs. something brand new that could
   possibly be implemented with new SDN technology like Protocol
   Oblivious Forwarding-POF.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ashwood-sdnrg-state-reduction

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ashwood-sdnrg-state-reduction-00

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

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

From: "Adrian Farrel" <[email-masked]>
To: "'Robert Raszuk'" <[email-masked]>, <[email-masked]>
Date: Tue, 2 Jul 2013 17:09:41 +0100
Subject: Re: [Status] STATUS BOF
Reply-To: [email-masked]

Hi Robert,

Just chipping in...

5434 is "considerations for having a successful BoF" not "considerations for
granting a BoF request".

I *do* think that the likelihood of having a successful BoF would have been
increased by posting more drafts and having more public (and more-public)
discussions prior to meeting in Berlin. That said, there are a few more weeks, a
number of I-ds have been posted, a mailing list exists and no-one is even
slightly too busy to post lots of emails :-) 

We should also consider how we measure "success" for a BoF.  Will success look
like the formation of a working group? Or will it look like a good airing and
debate around the technical topics? Maybe success could be measured by the
extent to which the very existence of the BoF causes I-Ds to be posted and
conversations to be moved into public forums.

Anyway, I think the BoF chairs should be less your target than the ADs. The
chairs are doing us all (ADs and community) a service by trying to place the
whole herd of cats into one box (strangely marked "Property of Prof
Schrödinger"). They didn't request the BoF, and they didn't grant the BoF
request.

Cheers,
Adrian 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Robert Raszuk
> Sent: 01 July 2013 21:21
> To: [email-masked]
> Subject: [Status] STATUS BOF
> 
> Hi,
> 
> To better understand the scope of this BOF I took a look at the
> RFC5434 and found those guidelines:
> 
> 4)   Have substantive mailing list discussion.  It is not enough for a
>       handful of people to assert that they want a BOF; there needs to
>       be broader community interest.  A public mailing list allows ADs
>       (and others) to gauge how much interest there really is on a topic
>       area, as well as gauge how well the problem statement has been
>       scoped, etc.  At this phase of the BOF preparation, the emphasis
>       should be on getting agreement on the problem statement;
>       discussions about specific solutions tend to be distracting and
>       unhelpful.
> 
>       Timeline: this step can easily take 1 month or longer; hence,
>       begin 2.5 months before the IETF meeting.
> 
>    5) Submit a formal request to have a BOF.
> 
> 
> Can BOF chairs point us to archives of pre-BOF "substantive mailing
> list discussion" ?
> 
> Cheers,
> R,.
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

Date: Tue, 02 Jul 2013 10:15:24 +0100
From: Stewart Bryant <[email-masked]>
To: Robert Raszuk <[email-masked]>
Cc: Hannes Gredler <[email-masked]>, [email-masked]
Subject: Re: [Status] STATUS BOF
Reply-To: [email-masked]

Robert,

On 02/07/2013 09:51, Robert Raszuk wrote:
> Hey Hannes,
>
>> i had a look at the "introduction" section of RFC 5434 and
>> could not find anything offending.
> I was not claiming RFC5434 contains any thing offending either :)
>
>> all of the above is applicable -
>> since 2012, several vendors and their customers have worked together on
>> dissemination of fixed size "Segment-IDs" and "Labels" by the IGP,
>> its use-cases and applicability.
> Hmmm I recall we have had similar discussions in 2002 ! In fact there
> are for sure some written records of it.

Sometimes an idea needs to be born in its own time.

If you have pointers to drafts, perhaps you can post them.
>
>> Asking for a BOF is a good thing because it carries some of those ideas,
>> private write-ups and discussion to the daylight of IETF.
> As you know this work is based on the IGP extensions. Those are
> already published in daylight to ISIS and OSPF WG. Likewise some
> products and applications will be done in subject specific WGs -
> example PCE (also draft is published).
Which drafts are you referring to, and how is this consistent with
your earlier reference to 2002 work? Are they the same or different?

>
> There is going to also be work in IPv6 WGs and maybe in MPLS WG.
>
>> i fail to see whats wrong with that;
> Nothing is wrong till the moment that this WG will attempt to block or
> derail progress of other parallel work.
>
Firstly this is not yet a WG, it is an investigation on if/how the IETF
should work on this technology.

Secondly when you get a technology that spans many WGs the IETF
normally investigates how that work should be aligned and co-ordinated
and in some cases moves it to a single place.

- Stewart

Date: Tue, 02 Jul 2013 10:07:43 +0100
From: Stewart Bryant <[email-masked]>
To: Hannes Gredler <[email-masked]>
Cc: [email-masked], Robert Raszuk <[email-masked]>
Subject: Re: [Status] STATUS BOF
Reply-To: [email-masked]

On 02/07/2013 06:48, Hannes Gredler wrote:
> since 2012, several vendors and their customers have worked together on
> dissemination of fixed size "Segment-IDs" and "Labels" by the IGP,
> its use-cases and applicability.
>
> Asking for a BOF is a good thing because it carries some of those ideas,
> private write-ups and discussion to the daylight of IETF.
>
The ADs were aware of these discussions and had been planning a mini-bof
prior to receiving a formal BOF request.

The technology is clearly in the scope of the IETF and spans a number
of WGs. It is important that the IETF takes a holistic view of the
space to determine if/how best to work on it and if/how to publish any
necessary RFCs. A non-wg BOF is a commonly used tool to consider
such matters, and that is what is planned for Berlin.

Stewart

Sender: [email-masked]
Date: Tue, 2 Jul 2013 10:54:14 +0200
From: Robert Raszuk <[email-masked]>
To: Loa Andersson <[email-masked]>
Cc: John E Drake <[email-masked]>, "[email-masked]" <[email-masked]>, "Alvaro Retana \(aretana\)" <[email-masked]>
Subject: Re: [Status] Call for Presentations (status BOF)

Hi Loa,

Yes. I stay corrected .. forgot "-ing".

Fortunately the "-ing" does not change nor impacts in any way the
fundamental sense of the message.

Cheers,
R.

> On Tue, Jul 2, 2013 at 9:26 AM, Loa Andersson <[email-masked]> wrote:
> Robert, etal.,
>
> what might seem as a nit.
>
> LSR stands for Label Switching Router, not Label Switch Router.
>
> /Loa
>
>
> On 2013-07-01 23:57, Robert Raszuk wrote:
>>
>> Hello John,
>>
>> Looking forward to your presentation.
>>
>> In fact it would be great if it includes both deployment scenarios:
>>
>> * MPLS architecture with MPLS label switching and MPLS label swapping
>> at each LSR
>>
>> * MPLS architecture with MPLS label switching and NO MPLS label
>> swapping at each LSR
>>
>> After all LSR stands for Label Switch Router not Label Switch-&-Swap
>> Router ;)
>>
>> Best regards,
>> R.

Sender: [email-masked]
Date: Tue, 2 Jul 2013 10:51:13 +0200
From: Robert Raszuk <[email-masked]>
To: Hannes Gredler <[email-masked]>
Cc: [email-masked]
Subject: Re: [Status] STATUS BOF

Hey Hannes,

> i had a look at the "introduction" section of RFC 5434 and
> could not find anything offending.

I was not claiming RFC5434 contains any thing offending either :)

> all of the above is applicable -
> since 2012, several vendors and their customers have worked together on
> dissemination of fixed size "Segment-IDs" and "Labels" by the IGP,
> its use-cases and applicability.

Hmmm I recall we have had similar discussions in 2002 ! In fact there
are for sure some written records of it.

> Asking for a BOF is a good thing because it carries some of those ideas,
> private write-ups and discussion to the daylight of IETF.

As you know this work is based on the IGP extensions. Those are
already published in daylight to ISIS and OSPF WG. Likewise some
products and applications will be done in subject specific WGs -
example PCE (also draft is published).

There is going to also be work in IPv6 WGs and maybe in MPLS WG.

> i fail to see whats wrong with that;

Nothing is wrong till the moment that this WG will attempt to block or
derail progress of other parallel work.

Cheers,
R.

> On Jul 1, 2013, at 10:20 PM, Robert Raszuk wrote:
>
>> Hi,
>>
>> To better understand the scope of this BOF I took a look at the
>> RFC5434 and found those guidelines:
>>
>> 4)   Have substantive mailing list discussion.  It is not enough for a
>>      handful of people to assert that they want a BOF; there needs to
>>      be broader community interest.  A public mailing list allows ADs
>>      (and others) to gauge how much interest there really is on a topic
>>      area, as well as gauge how well the problem statement has been
>>      scoped, etc.  At this phase of the BOF preparation, the emphasis
>>      should be on getting agreement on the problem statement;
>>      discussions about specific solutions tend to be distracting and
>>      unhelpful.
>>
>>      Timeline: this step can easily take 1 month or longer; hence,
>>      begin 2.5 months before the IETF meeting.
>>
>>   5) Submit a formal request to have a BOF.
>>
>>
>> Can BOF chairs point us to archives of pre-BOF "substantive mailing
>> list discussion" ?
>
>
>

Date: Tue, 02 Jul 2013 09:26:46 +0200
From: Loa Andersson <[email-masked]>
To: Robert Raszuk <[email-masked]>
Cc: John E Drake <[email-masked]>, "[email-masked]" <[email-masked]>, "Alvaro Retana \(aretana\)" <[email-masked]>
Subject: Re: [Status] Call for Presentations (status BOF)

Robert, etal.,

what might seem as a nit.

LSR stands for Label Switching Router, not Label Switch Router.

/Loa

On 2013-07-01 23:57, Robert Raszuk wrote:
> Hello John,
>
> Looking forward to your presentation.
>
> In fact it would be great if it includes both deployment scenarios:
>
> * MPLS architecture with MPLS label switching and MPLS label swapping
> at each LSR
>
> * MPLS architecture with MPLS label switching and NO MPLS label
> swapping at each LSR
>
> After all LSR stands for Label Switch Router not Label Switch-&-Swap Router ;)
>
> Best regards,
> R.
>
>
>> On Mon, Jul 1, 2013 at 5:17 PM, John E Drake <[email-masked]> wrote:
>>
>> Alvaro,
>>
>> I would like to request a ten minute slot at the status BoF to explain how
>> source routing fits into the existing MPLS architecture.
>>
>> Yours Irrespectively,
>> John
> _______________________________________________
> 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: Hannes Gredler <[email-masked]>
Date: Tue, 2 Jul 2013 07:48:22 +0200
To: Robert Raszuk <[email-masked]>
Cc: [email-masked]
Subject: Re: [Status] STATUS BOF

robert,

i had a look at the "introduction" section of RFC 5434 and
could not find anything offending.

--
   This document provides suggestions on how to host a successful BOF at
   an IETF meeting.  It is hoped that by documenting the methodologies
   that have proven successful, as well as listing some pitfalls, BOF
   organizers will improve their chances of hosting a BOF with a
   positive outcome.

   There are many reasons for hosting a BOF.  Some BOFs are not intended
   to result in the formation of a Working Group (WG).  For example, a
   BOF might be a one-shot presentation on a particular issue, in order
   to provide information to the IETF Community.  Another example might
   be to host an open meeting to discuss specific open issues with a
   document that is not associated with an active WG, but for which
   face-to-face interaction is needed to resolve issues.  In many cases,
   however, the intent is to form a WG.  In those cases, the goal of the
   BOF is to demonstrate that the community has agreement that:

      - there is a problem that needs solving, and the IETF is the right
        group to attempt solving it.

      - there is a critical mass of participants willing to work on the
        problem (e.g., write drafts, review drafts, etc.).

      - the scope of the problem is well defined and understood, that
        is, people generally understand what the WG will work on (and
        what it won't) and what its actual deliverables will be.

      - there is agreement that the specific deliverables (i.e.,
        proposed documents) are the right set.

      - it is believed that the WG has a reasonable probability of
        having success (i.e., in completing the deliverables in its
        charter in a timely fashion).

--

all of the above is applicable - 
since 2012, several vendors and their customers have worked together on
dissemination of fixed size "Segment-IDs" and "Labels" by the IGP,
its use-cases and applicability.

Asking for a BOF is a good thing because it carries some of those ideas,
private write-ups and discussion to the daylight of IETF.

i fail to see whats wrong with that;

/hannes

On Jul 1, 2013, at 10:20 PM, Robert Raszuk wrote:

> Hi,
> 
> To better understand the scope of this BOF I took a look at the
> RFC5434 and found those guidelines:
> 
> 4)   Have substantive mailing list discussion.  It is not enough for a
>      handful of people to assert that they want a BOF; there needs to
>      be broader community interest.  A public mailing list allows ADs
>      (and others) to gauge how much interest there really is on a topic
>      area, as well as gauge how well the problem statement has been
>      scoped, etc.  At this phase of the BOF preparation, the emphasis
>      should be on getting agreement on the problem statement;
>      discussions about specific solutions tend to be distracting and
>      unhelpful.
> 
>      Timeline: this step can easily take 1 month or longer; hence,
>      begin 2.5 months before the IETF meeting.
> 
>   5) Submit a formal request to have a BOF.
> 
> 
> Can BOF chairs point us to archives of pre-BOF "substantive mailing
> list discussion" ?

From: John E Drake <[email-masked]>
To: Robert Raszuk <[email-masked]>
Date: Mon, 1 Jul 2013 22:03:10 +0000
Accept-Language: en-US
Cc: "Alvaro Retana \(aretana\)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Call for Presentations (status BOF)

Robert,

Thanks, this is helpful.

Yours Irrespectively,

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert
> Raszuk
> Sent: Monday, July 01, 2013 2:57 PM
> To: John E Drake
> Cc: Alvaro Retana (aretana); [email-masked]
> Subject: Re: [Status] Call for Presentations (status BOF)
> 
> Hello John,
> 
> Looking forward to your presentation.
> 
> In fact it would be great if it includes both deployment scenarios:
> 
> * MPLS architecture with MPLS label switching and MPLS label swapping
> at each LSR
> 
> * MPLS architecture with MPLS label switching and NO MPLS label
> swapping at each LSR
> 
> After all LSR stands for Label Switch Router not Label Switch-&-Swap
> Router ;)
> 
> Best regards,
> R.
> 
> 
> > On Mon, Jul 1, 2013 at 5:17 PM, John E Drake <[email-masked]>
> wrote:
> >
> > Alvaro,
> >
> > I would like to request a ten minute slot at the status BoF to
> explain
> > how source routing fits into the existing MPLS architecture.
> >
> > Yours Irrespectively,
> > John
> 

Sender: [email-masked]
Date: Mon, 1 Jul 2013 23:57:22 +0200
From: Robert Raszuk <[email-masked]>
To: John E Drake <[email-masked]>
Cc: "Alvaro Retana \(aretana\)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Call for Presentations (status BOF)

Hello John,

Looking forward to your presentation.

In fact it would be great if it includes both deployment scenarios:

* MPLS architecture with MPLS label switching and MPLS label swapping
at each LSR

* MPLS architecture with MPLS label switching and NO MPLS label
swapping at each LSR

After all LSR stands for Label Switch Router not Label Switch-&-Swap Router ;)

Best regards,
R.

> On Mon, Jul 1, 2013 at 5:17 PM, John E Drake <[email-masked]> wrote:
>
> Alvaro,
>
> I would like to request a ten minute slot at the status BoF to explain how
> source routing fits into the existing MPLS architecture.
>
> Yours Irrespectively,
> John

Sender: [email-masked]
Date: Mon, 1 Jul 2013 22:20:51 +0200
From: Robert Raszuk <[email-masked]>
To: [email-masked]
Subject: [Status] STATUS BOF

Hi,

To better understand the scope of this BOF I took a look at the
RFC5434 and found those guidelines:

4)   Have substantive mailing list discussion.  It is not enough for a
      handful of people to assert that they want a BOF; there needs to
      be broader community interest.  A public mailing list allows ADs
      (and others) to gauge how much interest there really is on a topic
      area, as well as gauge how well the problem statement has been
      scoped, etc.  At this phase of the BOF preparation, the emphasis
      should be on getting agreement on the problem statement;
      discussions about specific solutions tend to be distracting and
      unhelpful.

      Timeline: this step can easily take 1 month or longer; hence,
      begin 2.5 months before the IETF meeting.

   5) Submit a formal request to have a BOF.

Can BOF chairs point us to archives of pre-BOF "substantive mailing
list discussion" ?

Cheers,
R,.

From: "John G. Scudder" <[email-masked]>
Date: Mon, 1 Jul 2013 11:59:14 -0400
To: Stefano Previdi <[email-masked]>, John E Drake <[email-masked]>, Rob Shakir <[email-masked]>, AshwoodsmithPeter <[email-masked]>,  Hannes Gredler <[email-masked]>, "[email-masked]" <[email-masked]>, <[email-masked]>, Victor Kuarsingh <[email-masked]>
Cc: "<[email-masked]> \(aretana\)" <[email-masked]>, [email-masked], Clarence Filsfils <[email-masked]>
Subject: [Status] Call for Presentations (status BOF)

Those in the "to" line: We've received your request for a presentation slot. At the moment, based on the requests we've received so far, it looks likely we'll be able to accommodate you with the amount of time you requested. This could change. 

If you requested a presentation slot and are not listed in the "to" line, I've missed your request, please let me know.

If you have not requested a presentation slot but were thinking about doing so, you should take this as a hint to stop thinking and make your request.

Also, please remember:

> To optimize the discussion at the meeting itself, we will be asking the presenters to have their slides ready several days in advance.  We will determine the exact date once the IETF agenda has been published and will strictly adhere to a "no slides, no slot" rule.  Also, please post any related drafts as soon as possible and send a brief description to the list.

Hint, now would not be too soon to get a first draft of your slides to us.

Thanks,

--John and Alvaro

From: John E Drake <[email-masked]>
To: "Alvaro Retana (aretana)" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 1 Jul 2013 15:17:57 +0000
Accept-Language: en-US
Subject: Re: [Status] Call for Presentations (status BOF)

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

Alvaro,

I would like to request a ten minute slot at the status BoF to explain how source routing fits into the existing MPLS architecture.

Yours Irrespectively,

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alvaro Retana (aretana)
Sent: Monday, June 24, 2013 9:27 PM
To: [email-masked]
Subject: [Status] Call for Presentations (status BOF)

Hi!

As all of you on the list know, we will be holding a status (Stacked Tunnels for Source Routing) BOF in Berlin.  The details are listed in the BoF page:  http://trac.tools.ietf.org/bof/trac/

This message is the formal call for presentations.  Given the exploratory nature of the BoF, we would like to explicitly request talks from network operators about use cases and requirements, as well as others describing potential architectures.

To optimize the discussion at the meeting itself, we will be asking the presenters to have their slides ready several days in advance.  We will determine the exact date once the IETF agenda has been published and will strictly adhere to a "no slides, no slot" rule.  Also, please post any related drafts as soon as possible and send a brief description to the list.

Thanks!

Alvaro + John

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

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 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";}
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]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Alvaro,<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 would like to request a ten minute slot at the status BoF to explain how source routing fits into the existing MPLS architecture.<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 #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> [email-masked] [mailto:[email-masked]]
<b>On Behalf Of </b>Alvaro Retana (aretana)<br>
<b>Sent:</b> Monday, June 24, 2013 9:27 PM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> [Status] Call for Presentations (status BOF)<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">Hi!<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">As all of you on the list know, we will be holding a status (Stacked Tunnels for Source Routing) BOF in Berlin. &nbsp;The details are listed in the BoF page: &nbsp;<a href="http://trac.tools.ietf.org/bof/trac">http://trac.tools.ietf.org/bof/trac</a>/<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">This message is the formal call for presentations. &nbsp;Given the exploratory nature of the BoF, we would like to explicitly request talks from network operators
 about use cases and requirements, as well as others describing potential architectures. &nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">To optimize the discussion at the meeting itself, we will be asking the presenters to have their slides ready several days in advance. &nbsp;We will determine the
 exact date once the IETF agenda has been published and will strictly adhere to a &quot;no slides, no slot&quot; rule. &nbsp;Also, please post any related drafts as soon as possible and send a brief description to the list.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">Thanks!<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">Alvaro &#43; John<o:p></o:p></span></p>
</div>
</div>
</div>
</body>
</html>

--_000_0182DEA5604B3A44A2EE61F3EE3ED69E1D545E8CBL2PRD0510MB349_--