Subject: [mpls] Proposed response to Ring Protection Liaison

From: Ross Callon <[email-masked]>
Date: Fri, 11 Jan 2013 18:50:38 +0000

We've had a small team that prepared a response to an incoming liaison
from ITU-T SG15 on ring protection. The incoming liaison is:

    2012-10-03  ITU-T SG 15     Multiprotocol Label Switching   2012-12-31
                 Requirements and analysis of ring protection
                 for MPLS-TP networks
                 http://datatracker.ietf.org/liaison/1199/

The proposed response is attached.

Please send comments on the proposed response to the MPLS working group mailing
list ([email-masked]<mailto:[email-masked]>) by next Friday (January 18, 2013).

Thanks, Ross
(as MPLS WG co-chair)

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 12 Jan 2013 18:39:13 -0000

Hi Ross,
 
Many thanks for driving this.
 
It's somehow appropriate to write a liaison to the ITU-T in Microsoft Word :-)
 
I have some comments (as an individual).
 
---
 
I assume the chairs will top and tail this liaison with the usual polite
niceties. In particular, we should welcome the way that SG15 is engaging with
the MPLS working group on ring protection requirements. 
 
---
 
I suggest using a different numbering scheme to avoid confusion between the two
lists of requirements. Include the text:
"To avoid confusion we have numbered the suggested requirements in your Liaison
as IR1, IR2, etc. and we refer to the requirements in RFC 5654 using the
notation as published (i.e., R96, R97, etc.)."
And then, obviously, fix the liaison text accordingly.
 
---
 
This draft does not seem to answer the first noted requirements in the incoming
liaison viz.
| Requirements for ITU-T G.8132 
| Requirements and optimization criteria for ring protection specified in
RFC5654 "MPLS-TP
| requirements" have to be taken into account.
 
I think this deserves the response:
We agree that the requirements and optimization criteria for ring protection set
out in RFC 5654 should be taken into account. In particular, we draw your
attention to the preamble in Section 2.5.6.1 and the statements made about the
cost/benefit implications of specialised protection solutions.
 
----
 
In your second paragraph, I don't think it is necessary to say "Adding new
requirements for a technology already in active development and deployment is
not to be taken lightly," I am sure that the ITU-T is well aware of the risks of
moving goalposts. Of course, neither of the proposed requirements IR2 and IR3
proposes a change to linear protection - they are both requirements placed on
ring protection. In my view IR2 may make a specialist ring protection scheme
almost impossible to devise since it would have to seamlessly upgrade from
linear protection.
 
So, I think you should:
- delete the apple pie text
- invite new requirements to be raised within the MPLS WG using the normal IETF
process
 
---
 
I am not a huge fan of holding technical debate via liaison statement. That said
your observations on T1 and T2 are correct.
 
---
 
In your discussion of T2 you say:
 
> The IETF believes in topology-independent mechanisms whenever possible,
> as prescribing or proscribing specific network architectures is outside the
> IETF's scope.
 
I wonder whether you can give me a reference for this statement. AFAICS there
are plenty of examples of the IETF recommending specific technologies/solutions
for specific environments/networks.  You might say that, as a general rule, the
IETF has tended to try to avoid optimizing for special cases. Or you might
simply delete this sentence.
 
---
 
Later in the discussion of T2 you say:
 
> The IETF believes that the reuse of linear protection mechanisms
> in a ring topology (i.e. draft-ietf-mpls-tp-ring-protection) will meet
> performance targets in a ring topology, and will do so while allowing
> the operator to deploy a single protection method across all possible
> network topologies.
 
I do not believe it is your intention to test IETF consensus on this before
sending the liaison. You might s/IETF/MPLS working group/ and use the review of
this liaison statement as the way to test that consensus.
 
When you say "the performance targets" you should append "expressed in RFC
5654".
 
---
 
The paragraph on the sophistication of ring-based networks is undoubtedly true.
Even in traditional transport networks, ring interconnects have made end-to-end
paths appear to traverse a mesh. The ease with which packet networks can bridge
between rings makes the meshiness all the more likely. 
 
Notwithstanding that, there is (or it could be argued that there is) value in
imposing logical protection domains in mesh networks. By treating a portion of
the mesh network as a logical ring, certain specific ring protection
characteristics (such as those discussed in draft-ietf-mpls-tp-ring-protection)
can be leveraged.
 
So, I am wondering what this paragraph is attempting to add to the liaison.
 
---
 
The way you handle answering C-2098 is correct, but maybe s/C-2098/C-2098
referenced from Annex 2/
 
Also s/IETF's Fast ReRoute./IETF's MPLS Fast ReRoute described in RFC 4090/
 
And then, s/The IETF recommends/The MPLS working group recommends/  (assuming
you have consensus for that)
 
---
 
The incoming liaison also says:
 
| We would also like to know status of the individual/working group
| drafts containing MPLS-TP ring protection solutions.
 
This needs an answer, and the chairs are probably best placed to craft it.
Something like...
"draft-ietf-mpls-tp-ring-protection describes the applicability of the generic
linear protection mechanisms (RFC 6378) to ring topologies. As such it sets a
baseline for determining the optimization value of any other proposed solutions.
This draft also discusses a number of the different mechanisms that can be used
in ring protection and highlights the optimizations that can be made in packet
networks as compared to traditional transport networks where tunnelling is not
so readily available. The status of this draft is foo.
There are also a considerable number of individual drafts proposing different
solutions and addressing different aspects of ring protection. The chairs hope
that these documents will be discussed further on the MPLS mailing list so that
it becomes clear which offer the best solutions addressing all the requirements
and providing optimization benefits. The chairs also hope that the authors of
the various drafts will attempt to find compromise positions that allow their
approaches to be merged. Lastly, the chairs hope to hear of intent to implement
that will clearly show which drafts have concrete support."
 
---
 
Finally, and off the topic of the liaison response, I wonder whether the chairs
have time on the agenda in Orlando to allow a 20 minute (or so) slot discussing
ring protection to determine what the next steps are for the WG. Maybe one of
the ITU-T experts who attend the IETF could lead a discussion based on the
received Annex 2.
 
---
 
Thanks!
Adrian
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ross
Callon
Sent: 11 January 2013 18:51
To: [email-masked]
Subject: [mpls] Proposed response to Ring Protection Liaison

 
 
Please send comments on the proposed response to the MPLS working group mailing
list ([email-masked]) by next Friday (January 18, 2013). 
 
Thanks, Ross
(as MPLS WG co-chair)

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Tue, 15 Jan 2013 18:04:54 +0000

Hi Adrian-

  Inline with EO#.  I've also attached a marked-up Word doc with the proposed changes.  

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Adrian Farrel
> Sent: Saturday, January 12, 2013 1:39 PM
> To: 'Ross Callon'
> Cc: [email-masked]
> Subject: Re: [mpls] Proposed response to Ring Protection Liaison
> 
> Hi Ross,
> 

EO#  The LS came in as PDF, but Word's much easier to edit.  When it's done we should probably send it as PDF. 
> I assume the chairs will top and tail this liaison with the usual polite niceties. In
> particular, we should welcome the way that SG15 is engaging with the MPLS
> working group on ring protection requirements.
> 

EO#  I'm not a chair and am good at neither polite nor nice, so I've left these bits out of my edits.

> ---
> 
> I suggest using a different numbering scheme to avoid confusion between the
> two lists of requirements. Include the text:
> "To avoid confusion we have numbered the suggested requirements in your
> Liaison as IR1, IR2, etc. and we refer to the requirements in RFC 5654 using the

EO#  Done.

> ---
> 
> This draft does not seem to answer the first noted requirements in the
> incoming liaison viz.
> | Requirements and optimization criteria for ring protection specified
> | in RFC5654 "MPLS-TP requirements" have to be taken into account.
> 
> We agree that the requirements and optimization criteria for ring protection
> set out in RFC 5654 should be taken into account. In particular, we draw your

EO#  I could go either way on this, but I've added your text. 

> requirements for a technology already in active development and deployment
> is not to be taken lightly," I am sure that the ITU-T is well aware of the risks of
> ring protection. 

EO# When I wrote 'in active deployment' I meant the text in rfc5654, not rfc6378.  Of course, it's not actually possible to have deployed a set of requirements.

> In my view IR2 may make a specialist ring protection scheme

EO#  They could be run as ships-in-the-night and then migrated away from, I guess.  That'd move it from 'almost impossible' to 'quite difficult'.

> - invite new requirements to be raised within the MPLS WG using the normal
> IETF process
> 

EO#  Done.  I debated suggesting that R2 s/network upgrade/network migration/ and R3 s/upgrade/resize/ (particularly as one could both grow and shrink a ring as part of the normal course of operations) but I'll leave that for the standard WG bashing.

> your observations on T1 and T2 are correct.

EO#  What is the correct vehicle for technical debate?  Discussion on the IETF list?  Discussion first followed by a LS to formalize the discussion points?  I've added some text to this effect as a start - "For the technical analysis, we invite the discussion of these scenarios on the MPLS WG email list, as that may help to progress a technical solution more effectively than liaison statements."

> > The IETF believes in topology-independent mechanisms whenever
> > possible, as prescribing or proscribing specific network architectures
> > is outside the IETF's scope.
> 
> are plenty of examples of the IETF recommending specific
> technologies/solutions for specific environments/networks.  You might say that,
> as a general rule, the IETF has tended to try to avoid optimizing for special
> cases. Or you might simply delete this sentence.

EO#  I'd much rather delete it than argue IETF history with you, as I'm pretty sure I'd get my hat handed to me.  Deleted.

> > The IETF believes that the reuse of linear protection mechanisms in a
> > ring topology (i.e. draft-ietf-mpls-tp-ring-protection) will meet
> I do not believe it is your intention to test IETF consensus on this before sending
> the liaison. You might s/IETF/MPLS working group/ and use the review of this
> liaison statement as the way to test that consensus.

EO#  s/IETF/MPLS WG/ done.  I'm going to stay away from the consensus point on this thread, as that's a whole separate thing, but I do note that the ring protection doc is a WG draft and thus has at least some level of enthusiasm behind it.

> When you say "the performance targets" you should append "expressed in RFC

EO#  Done.

> ---
> 
> The paragraph on the sophistication of ring-based networks is undoubtedly
> true. Even in traditional transport networks, ring interconnects have made end-
> to-end paths appear to traverse a mesh. The ease with which packet networks
> can bridge between rings makes the meshiness all the more likely.
> 

EO#  This point, I think, is important.

It was an attempt to say "if we're going to discuss ring-specific mechanisms we should agree when something is and is not a ring".  'Ring' has very particular significance in the transport world, and the text was an attempt to draw out that definition.  Some members of the WG (ok...probably just me) do not understand the distinction between a sufficiently sophisticated ring and a mesh.  I'd hate to come up with an agreement on what ring-specific protection looks like only to find out post hoc that one side meant "a set of no more than 16 nodes [A---B---C---...---P--A] which constitute the entirety of a given ring-specific protection domain" and the other meant "an arbitrary mesh that has been subdivided into little circles but with end-to-end protection across the ringmesh" or something like that.  In my opinion understanding the definition is key to scoping the requirements properly.  

> The way you handle answering C-2098 is correct, but maybe s/C-2098/C-2098

EO#  Added a few words to do this.

> Also s/IETF's Fast ReRoute./IETF's MPLS Fast ReRoute described in RFC 4090/

EO#  Done.

> And then, s/The IETF recommends/The MPLS working group recommends/
> (assuming you have consensus for that)
> 

EO#  Done

> | drafts containing MPLS-TP ring protection solutions.

EO#  Thanks, clearly we missed that.  Added your text in the beginning of the document as a placeholder so the chairs can edit as necessary.

Ross, Scott, others - comments and edit pen as necessary.

eric

> baseline for determining the optimization value of any other proposed
> solutions. This draft also discusses a number of the different mechanisms that
> can be used in ring protection and highlights the optimizations that can be
> made in packet networks as compared to traditional transport networks where
> tunnelling is not so readily available. The status of this draft is foo.
> approaches to be merged. Lastly, the chairs hope to hear of intent to
> implement that will clearly show which drafts have concrete support."
> 
> ---
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ross Callon
> We've had a small team that prepared a response to an incoming liaison from
> ITU-T SG15 on ring protection. The incoming liaison is:
> 
> Please send comments on the proposed response to the MPLS working group
> mailing list ([email-masked]) by next Friday (January 18, 2013).
> 
> Thanks, Ross
> (as MPLS WG co-chair)
> 
> 
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 16 Jan 2013 22:50:53 -0000

Thanks Eric (proxying for Ross :-)

Good progress.

[snip]

> should probably send it as PDF.

Not very used to seeing proprietary format documents on the IETF mailing lists.

> > I assume the chairs will top and tail this liaison with the usual polite
niceties. In
> EO#  I'm not a chair and am good at neither polite nor nice, so I've left
these bits
> out of my edits.

Fair enough. And I am still sure the chairs will top and tail.

[snip]

> > attention to the preamble in Section 2.5.6.1 and the statements made about
> > the cost/benefit implications of specialised protection solutions.
> 

You added an additional sentence.

I don't really object, but it puzzles me that you refer to G.8132 when it is
enough to address the text in the liaison.

[snip]

> EO#  What is the correct vehicle for technical debate?  Discussion on the IETF
list?
> Discussion first followed by a LS to formalize the discussion points?  I've
added
> some text to this effect as a start - "For the technical analysis, we invite
the
> discussion of these scenarios on the MPLS WG email list, as that may help to
> progress a technical solution more effectively than liaison statements."

My personal opinion is that we are the IETF and the correct vehicle for
technical debates is the appropriate working group mailing list, possibly
supported by an IETF draft.

I would strike the second half of the sentence. Effectiveness may or may not be
relevant. Regardless of that, we invite discussion on the mailing list.

> > sending  the liaison. You might s/IETF/MPLS working group/ and use the
> > review of this liaison statement as the way to test that consensus.
> 
> EO#  s/IETF/MPLS WG/ done.  I'm going to stay away from the consensus point
> on this thread, as that's a whole separate thing, but I do note that the ring
> protection doc is a WG draft and thus has at least some level of enthusiasm
> behind it.

The chairs will need to believe there is WG consensus on this point if they
intend to send a liaison statement that says the WG believes something. The
chairs might consider that putting this draft liaison statement out for WG
review gives enough evidence on which to build that belief.

[snip]

> It was an attempt to say "if we're going to discuss ring-specific mechanisms
we
> should agree when something is and is not a ring".  'Ring' has very particular
> significance in the transport world, and the text was an attempt to draw out
that
> definition.  Some members of the WG (ok...probably just me) do not understand
> the distinction between a sufficiently sophisticated ring and a mesh.  I'd
hate to
> come up with an agreement on what ring-specific protection looks like only to
> find out post hoc that one side meant "a set of no more than 16 nodes
[A---B---C-
> --...---P--A] which constitute the entirety of a given ring-specific
protection
> domain" and the other meant "an arbitrary mesh that has been subdivided into
> little circles but with end-to-end protection across the ringmesh" or
something
> like that.  In my opinion understanding the definition is key to scoping the
> requirements properly.

Yes, but what is the paragraph actually saying to the ITU-T?

Would it perhaps be better to ask the ITU-T for a clear definition of what they
mean by a ring network considering that rings may be multiply interconnected and
overlapping? [Note that changes this into a liaison For Action.]

[snip]
 
> > (assuming you have consensus for that)

Same point for the chairs to note wrt consensus for this.

Thanks for the work.

Adrian (an individual again)

---

From: "Hejia (Jia)" <[email-masked]>
Date: Fri, 18 Jan 2013 07:24:38 +0000

Hi all,

I concur with most of Adrian's comments and appreciate the changes made by Eric, and support sending the response to ITU-T. But I still have one more comment on the paragraph about T1 in the draft LS, quoted below:

T1 presents a scenario where linear protection would not suffice in the face of multiple failures. The given scenario is only one possible deployment model. There are others where linear protection would suffice. One such model is the wrapping protection as defined in draft-ietf-mpls-tp-ring-protection, and another is treating the aggregation and access networks as separate protection domains.

It is a bit confusing. Does it mean the examples of wrapping in draft-ietf-mpls-tp-ring-protection and "separate protection domains" do not satisfy the given scenario described by the ITU-T LS? If the described scenario in ITU-T LS also belongs to multiple failure situation, It is not so convincing to say " The given scenario is only one possible deployment model. There are others where linear protection would suffice". Perhaps it is better to clarify the scope of "multiple failures".

Am I missing anything?

B.R.
Jia

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Adrian Farrel
发送时间: 2013年1月17日 6:51
收件人: 'Eric Osborne (eosborne)'; 'Ross Callon'
抄送: [email-masked]
主题: Re: [mpls] Proposed response to Ring Protection Liaison

Good progress.

[snip]

niceties. In
these bits

[snip]

[snip]

list?
added
the

[snip]

we
that
hate to
[A---B---C-
protection
something

[snip]

Thanks for the work.

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