Subject: Y.1711 requirements from IETF

From: Shahram Davari <[email-masked]>
Date: Tue, 19 Mar 2002 13:21:04 -0800

Hi all,

To put things clear, as one of the authors of Y.1711 I would like to make some observations regarding 
the requirements that Y.1711 has from IETF. Off course an official response will be provided by ITU
to IETF in this regard.

1) Y.1711 requires only ONE reserved label (=14) for the identification of OAM packets.
2) No more labels is required to implement Y.1711 and no other label is anticipated to be required for future work.
3) The current version of Y.1711 provisions the egress LSRs for continuous monitoring of the 
CV (connectivity verification) packets. However, we thought that it might be beneficial to also
be able to signal to the egress LSR whether the CV is running on a specific LSP or not. There are
many ways of doing this (including using NMS) but the ideal way would be extensions to MPLS signaling protocols.
4) Y.1711 is fully backward compatible with IETF standards and has no intention of modifying any IETF protocol.
5) Y.1711 has no intention of adding any extensions to BGP or any other protocol (except optional
extensions to MPLS signaling as mentioned in 3).

Hope this helps.

Yours,
Shahram Davari
Senior Product Research Engineer
R&D Research Ottawa
PMC-Sierra, Inc. 
Phone: (613) 271-4018
Fax:   (613) 271-6468

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 19 Mar 2002 17:41:10 -0500

>2) No more labels is required to implement Y.1711 and no other label is 
>anticipated to be required for future work.
>CV (connectivity verification) packets.

         You should be clear. It specifies that *all* LSPs must be 
provisioned with this feature
on and at a specific interval.  I would check with operators on this, but I 
don't think this it is such a good
idea to tell operators how to run their networks.

>However, we thought that it might be beneficial to also

         The problem is that the details of this subtle point are not 
outlined in your current proposal.
Perhaps you could provide them here?

>4) Y.1711 is fully backward compatible with IETF standards and has no 
>intention of modifying any IETF protocol.

         How can you have "no intention" if you just stated in #3 that 
extensions to existing MPLS signaling
protocols may be needed.

>extensions to MPLS signaling as mentioned in 3).

         That is what we are worried about. Again, please provide the details.

         --Tom

>Senior Product Research Engineer

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.

---

From: [email-masked]
Date: Wed, 20 Mar 2002 01:59:06 -0000

Thomas D. Nadeau wrote 19 March 2002 22:41
> idea to tell operators how to run their networks.
NH=> Tom, I would not denigrate the ability of operators to read/understand
these documents.  Operators are not *forced* to turn-on CV everywhere and
there is not *must* here as you wrongly suggest.  The fixed period has a
different rationale .....if you want to have consistent/simple standards (ie
across vendors/operators) for defining the entry/exit criteria of defects
and their consequent actions, and esp if operators want to offer
availability/QoS SLAs, you need a deterministic period.  If you want to
offer similar functionality via some other method you would hopefully
realise you have exactly the same issues to face.

---

From: "David Allan"<[email-masked]>
Date: Tue, 19 Mar 2002 23:06:05 -0500

Folks

Seeing as information has been requested of the ITU on the subject of how
1711 functions will be controlled in the network, can we stop anticipating
the biblical scale of this disaster for sigalling until we have the facts
;-) 

It may only be a boolean attribute at LSP setup.....

cheers
Dave

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 20 Mar 2002 09:38:56 -0500

At 04:09 PM 3/19/2002 -0800, Shahram Davari wrote:
>Thomas,
>
> > -----Original Message-----
> > From: Thomas D. Nadeau [mailto:[email-masked]]
> > Sent: Tuesday, March 19, 2002 5:41 PM
> > To: Shahram Davari
> > Cc: [email-masked]'
> > Subject: Re: Y.1711 requirements from IETF
> >
> >
> >
> >
> > >To put things clear, as one of the authors of Y.1711 I would
> > like to make
> > >some observations regarding
> > >1) Y.1711 requires only ONE reserved label (=14) for the
> > identification of
> > >OAM packets.
> > >3) The current version of Y.1711 provisions the egress LSRs
> > for continuous
> > >monitoring of the
> > on and at a specific interval.
>
>
>Where did you get this " ALL LSPs MUST" statement from? May be you are
>reading a different Y.1711 than I have. All I can find are the following
>statement:
>
>" ... It is strongly recommended that CV OAM packets be generated on all LSPs
>(in order to detect all defects and potentially provide protection against
>traffic leakage both in and out of LSPs). "
>
>"... CV generation could be enabled on all (or most) of the LSPs"
>
>There is no MUST and in fact you could enable the CV only on ONE LSP.
>If the text is not conveying this information, then we would have
>to add additional text or appendix in the next version to clarify it.

         The text at strongly implies that it should be run everywhere all 
the time.
Not knowing the ITU language mapping from IETF MUST, MAY or
SHOULD, it is a reasonable assumption that the text you refer to
requires OAM to be run on every LSR and on every LSP.

>   I would check with operators
> > on this, but I
>We are not telling them how to run their network. All we are saying is
>that in order to detect more defects you need to enable more CVs. This is
>a compromise that they have to decide to make not us.
> > >many ways of doing this (including using NMS) but the ideal
> > way would be
> > >extensions to MPLS signaling protocols.
> >
>We have not worked out the details yet. The first version of Y.1711 relies on
>provisioning. In future we may or may not introduce new signaling extensions.
>
> >
>By modifying I meant mandatory extensions not optional extensions. Therefore
>we MAY  introduce optional extensions to MPLS signaling for enabling/disabling
>the OAM processing of the egress LSR.
>
> >
> > >5) Y.1711 has no intention of adding any extensions to BGP
> > or any other
> > >protocol (except optional
>I don't understand what is here that is hard to grasp for you.
>An optional extension is an optional TLV/object. Why is it important to
>know the details of the optional TLV/objects at this point in time?

         Because we were distinctly talking about the potential problems
or issues with ITU interaction the other day in the MPLS WG. I see
this as an issue (when and if you guys decided to ask for extensions
to any IETF protocols).

         --Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 20 Mar 2002 09:54:17 -0500

>realise you have exactly the same issues to face.

         Well who is to say that the 1 second period you specify (or
strongly recommend) in the document is desired or works for
all operators? Who is to say that 5 minutes will not work for
their particular installation?

         --Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 20 Mar 2002 09:59:46 -0500

At 11:06 PM 3/19/2002 -0500, David Allan wrote:

>the biblical scale of this disaster for sigalling until we have the facts ;-)

         All I am asking for are the facts. *)

         --Tom

---

From: Shahram Davari <[email-masked]>
Date: Wed, 20 Mar 2002 15:31:05 -0800

Thomas,

> requires OAM to be run on every LSR and on every LSP.

I think you are imagining things. Now you added one more imagination to your
comments : "..requires OAM to be run on every LSR". Where did you get this one
from?

For clarification OAM needs to be run only on edge LSRs, and you could 
turn it on or off on any LSP that you want.

-Shahram

---

From: [email-masked]
Date: Thu, 21 Mar 2002 11:00:33 -0000

Thomas D. Nadeau wrote 20 March 2002 14:54
 
> their particular installation?
NH=> Tom, I understand what you are saying here and yes you can do exactly
this.  But the consequences are as follows:
-	defect definitions (entry/exit) become intractably complex (or,
perhaps more accurately, no longer have any meaning)....I hope this is
obvious
-	there is no consistent application of consequent actions
-	there is no ability to define a consistent availability parameter
-	there is no consistent time-basis for defining the 'up-state' over
which any QoS metrics are relevant
-	and obviously there is no consistency across operators or vendors
wrt to parameters (not their objectives please note.....but also please be
aware that if we ever get around to apportioning an end-end performance
objectives to tandemed operator domains, then unless you have ensured
consistency of approach then this too will also not be possible.)

As I/Shahram indicated, there is no need to turn this stuff on anyway if you
don't need it...and for some applications you almost certainly won't.  But
it kind-of makes sense to me and our Ops guys, and I guess all the other
operators who worked on Y.1710/1711, that if you are going to use it then
consistency of behaviour is required for lots of reasons....and you can't do
this with variable CV emission rates.

However, if you never want any consistency, and just want to use ad hoc
techniques in all cases, then that is also fine....I would certainly never
wish to stop anyone using such an approach.

regards, Neil

---

From: "David Allan"<[email-masked]>
Date: Thu, 21 Mar 2002 09:21:28 -0500

George:

Is suggesting that all LSRs have the full internet routing table and MPLS
full connectivity a realistic example. 

I thought eliminating BGP in the core simply meant default route to the BGP
speakers, and full one-hop mesh of BGP speakers. Otherwise the internet
COULD not scale as every LSR would require a full routing table, and metrics
presumably would be leaked from BGP into the IGP. Could such a network
**EVER** converge?

cheers
Dave

> From: George Swallow [mailto:[email-masked]]
> Sent: Wednesday, March 20, 2002 5:59 PM
> To: Shahram Davari
> Cc: 'Thomas D. Nadeau'; [email-masked]'; [email-masked]
> I have one customer providing an IP VPN service who has >1500 PE
> routers and probably well over a million LSPs.  Most of the LSPs
> represent VPN connectivity can carry very little traffic.
> 
> Would you "strongly recommend" that CV OAM packets be generated on all
> their LSPs at a rate of 1 per second?  Can you point to *any*
> currently deployed network other than those using MPLS solely for
> traffic engineering where this would be a good idea?  If I'm carrying
> the full internet routing table and using LDP downstream unsolicited
> should every router generate 108,000 (the current number of routes) CV
> OAM packets per second?
> 
> Perhaps you should revisit this "strongly recommended"
> recommendation.  Perhaps you should provide for generation of CV OAM
> packets at rates other than 1  second.
> 
> ...George
> 
> ==================================================================
> George Swallow       Cisco Systems                  (978) 497-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
> 
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 21 Mar 2002 09:34:36 -0500

>turn it on or off on any LSP that you want.

         Two points. First, rarely is an LSR just an LSR, the argument
that this  needs to run "only on edge LSRs" could in reality mean
that it needs to run on every or nearly every LSR in a provider network.
Second, given the fact that many LSRs that also have PE functionality also
contain the entire Internet routing database when running LDP for LSP
tunnels, running this on devices doing edge duty at the "strongly
recommended" rate of 1 ping per LSP has ramifications for network bandwidth
on potentially every device.  Again, I recommend scaling back your
"strongly recommended" terminology, as it is clear that this is not
a solution that fits all networks.

         --Tom

---

From: Shahram Davari <[email-masked]>
Date: Thu, 21 Mar 2002 07:13:18 -0800

> Sent: Thursday, March 21, 2002 9:35 AM
> To: Shahram Davari
> Cc: [email-masked]'
> Subject: RE: Y.1711 requirements from IETF
> 
> 

But the same argument applies to MPLS-ping too. You also need to upgrade all LSRs.

-Shahram

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 21 Mar 2002 10:18:38 -0500

>But the same argument applies to MPLS-ping too. You also need to upgrade 

         You only have to patch the software for LSP Ping. With your
approach, hardware re-spin is required.

         --Tom

---

From: George Swallow <[email-masked]>
Date: Thu, 21 Mar 2002 10:24:32 -0500

>full connectivity a realistic example.

I got out of the business of telling operator how to run their networks 
long ago.  I would not suggest this, but
our implementation will support it.  The way most ISPs currently run, 
turning on LDP without doing anything
else will get you exactly the above.

>I thought eliminating BGP in the core simply meant default route to the 
>BGP speakers, and full one-hop mesh of BGP speakers. Otherwise the 
>internet COULD not scale as every LSR would require a full routing table, 
>and metrics presumably would be leaked from BGP into the IGP. Could such a 
>network **EVER** converge?

Yes you can use MPLS to eliminate BGP in the core.  Most ISPs today, 
however, are carrying the full internet routing table in *all* of their 
routers and they do converge.

...George

> > From: George Swallow [<mailto:[email-masked]>mailto:[email-masked]]

---

From: Shahram Davari <[email-masked]>
Date: Thu, 21 Mar 2002 08:07:20 -0800

But the same is true for MPLS-ping. You also need to ping all those FECs.

-Shahram

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 21 Mar 2002 11:16:39 -0500

Well, you MAY LSP ping all of those FECs if you wish and at
whatever rate you (i.e.: an operator) feels comfortable with. No one
is "strongly suggesting" that you do so at 1 packet per second.

         --Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 21 Mar 2002 11:22:48 -0500

That is up to the operator to configure. I am not in the
business of telling operators how to run their networks. I
just provide the tools and some suggestions.

         --Tom

>Sure, but then what is your fault detection time scale, and how do you 
>measure availability SLA?
>
>-Shahram
>
> > Sent: Thursday, March 21, 2002 11:17 AM
> > To: Shahram Davari
> > Cc: 'George Swallow'; [email-masked]'

---

From: Shahram Davari <[email-masked]>
Date: Thu, 21 Mar 2002 08:28:05 -0800

Deciding to run CV on LSPs is also left to the operators. But 1 CV/s is 
for interoperability and consistent availability measurements across
SPs, which off course you don't care about.

-Shahram

> Sent: Thursday, March 21, 2002 11:23 AM
> To: Shahram Davari

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 21 Mar 2002 11:37:56 -0500

>Deciding to run CV on LSPs is also left to the operators.

         Not the way Y.1711 reads.

>But 1 CV/s is

         Don't be ridiculous.  I think that disagreeing with your
proposal shows that I care a great deal about this space.

         --Tom

---

From: "David Allan"<[email-masked]>
Date: Thu, 21 Mar 2002 11:59:45 -0500

George:

Comments in line.

> else will get you exactly the above.  

Wasn't telling anyone anything, just commenting based on my understanding of
current practice.  
 
>> I thought eliminating BGP in the core simply meant default route to the
BGP speakers, and full one-hop mesh of BGP 
>> speakers. Otherwise the internet COULD not scale as every LSR would
require a full routing table, and metrics presumably 
>> would be leaked from BGP into the IGP. Could such a network **EVER**
converge?

> Yes you can use MPLS to eliminate BGP in the core.  Most ISPs today,
however, are carrying the full internet routing table 
> in *all* of their routers and they do converge. 

I stand corrected... 

cheers 
Dave

---

From: Shahram Davari <[email-masked]>
Date: Thu, 21 Mar 2002 09:22:40 -0800

Eric,

May be. I think ITU should decide about that.

-Shahram

> From: Eric Gray [mailto:[email-masked]]
> Sent: Thursday, March 21, 2002 12:19 PM
> To: Shahram Davari
> Cc: 'Thomas D. Nadeau'; 'George Swallow'; [email-masked]'
> Shahram,
>     Ah!
>     I understand that it can be quite frustrating to realize that you
> could have done less work.  Might it not be easier in the long
> run to revert to the simpler version?
> 
> You wrote:
> 
> >Eric,
> >
> >I didn't quite catch your question. If you are asking about 
> the 1/s transmission of CV,
> >then there are 2 choices in general:
> >
> >1) define one rate and define a globally accepted definition 
> of the availability and unavailability state and the
> >condition for their transitions. This guarantees 
> interoperability and global SLA measurement.
> >
> >2) Don't specify any rate or availability and unavailability 
> states and the transition conditions.
> >
> >Each has its advantage and disadvantage. They are two 
> different approaches. Some like to buy a car with ABS some 
> like to buy a car without ABS which are cheaper.
> >
> >In fact it would have been much easier for us to not specify 
> any rate, availability and state diagrams in Y.1711 and 
> reduce it to only 2-3 pages.
> >
> >-Shahram
> >
> >>From: Eric Gray [mailto:[email-masked]]
> >>Sent: Thursday, March 21, 2002 12:01 PM
> >>To: Shahram Davari
> >>Cc: 'Thomas D. Nadeau'; 'George Swallow'; [email-masked]'
> >>Shahram,
> >>    Speaking strictly as an individual, I do not understand 
> what your 
> >>reasons
> >>are for being quite so immovable on this topic.  Can you 
> >>explain why it 
> >>is that
> >>you feel it is so important to use (or at least not to change) the 
> >>current words?
> >>
> >>You wrote:
> >>
> >>>Sure, but then what is your fault detection time scale, and 
> >>>
> >>how do you measure availability SLA?
> >>
> >>>-Shahram
> >>>
> >>>>>But the same is true for MPLS-ping. You also need to ping 
> >>>>>
> >>>>all those FECs.
> >>>>
> >>>>>-Shahram
> >>>>>
> >>>>>>>Where did you get this " ALL LSPs MUST" statement from? May
> >>>>>>>
> >>>>>>be you are
> >>>>>>
> >>>>>>>reading a different Y.1711 than I have. All I can find are
> >>>>>>>
> >>>>>>the following
> >>>>>>
> >>>>>>>statement:
> >>>>>>>
> >>>>>>>" ... It is strongly recommended that CV OAM packets be
> >>>>>>>
> >>>>>>generated on all LSPs
> >>>>>>
> >>>>>>>(in order to detect all defects and potentially provide
> >>>>>>>
> >>>>>>protection against
> >>>>>>
> >>>>>>Would you "strongly recommend" that CV OAM packets be 
> >>>>>>
> >>>>generated on all
> >>>>
> >>>>>>traffic engineering where this would be a good idea?  If 
> >>>>>>
> >>>>I'm carrying
> >>>>
> >>>>>>the full internet routing table and using LDP downstream 
> >>>>>>
> >>>>unsolicited
> >>>>
> >>>>>>should every router generate 108,000 (the current number 
> >>>>>>
> >>>>of routes) CV
> >>>>
> >>>>>>OAM packets per second?
> >>>>>>
> >>>>>>recommendation.  Perhaps you should provide for 
> >>>>>>
> >>>>generation of CV OAM
> >>>>

---

From: [email-masked]
Date: Fri, 22 Mar 2002 01:17:02 -0000

Tom see my earlier comments......but please stop pushing all the problems
towards the operator to adddress, I think we have been given enough of these
already ;-)

Neil

> Sent: 21 March 2002 16:17
> To: Shahram Davari

---

From: [email-masked]
Date: Fri, 22 Mar 2002 01:17:05 -0000

Hi Eric....I have to ask....'simpler for whom'?
This is the no-free-lunch problem...by pushing a problem down in 1-dim it
has a nasty habit of   reappearing in another dim (and it seems some are
expert at this).  Operators would like consistent defects defintions since
these spawn the basis for availability and QoS metrics and, moreover,
consistency between vendors.....which has deeper corollaries for
apportioning end-end objectives betweeen domains.

regards, Neil

> Sent: 21 March 2002 17:19
> To: Shahram Davari

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 22 Mar 2002 12:46:45 -0500

Neil give me a break.  How do you figure that allowing an
operator to specify the interval at which to issue a ping or selecting
the LSPs on which to run the ping  "pushing all the problems towards
the operator."

         --Tom