Subject: [PWE3] Clarification request on VCCV CC types usage per PW

From: venkatesan mahalingam <[email-masked]>
Date: Mon, 12 Jul 2010 15:03:04 +0530

Hi PWE3 group,

In RFC-5085, section 5.3 VCCV capability advertisement for MPLS PWs, there
is no clarity about the CC type usage per PW.
So, can we have different CC type configurations per PW if the node supports
more than one CC types?

Example:
MPLS capable PW originating node supports all three CC types [1. ACH 2.
Router alert label 3. TTL expiry] for OAM packets demultiplexing.

In this case, please clarify the below configurations per PW is valid.

Can 3 PWs be setup with below configurations even though the PW originating
node supports all CC types?

1. PW-1 setup with ACH as CC type
2. PW-2 setup with Router alert label as CC type
3. PW-3 setup with TTL expiry as CC type

or

Does RFC mandate to send all supported CC types in all the three PWs?

-- 
Best Regards,
Venkatesan Mahalingam.

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 12 Jul 2010 08:05:32 -0400

> Hi PWE3 group,
>  
> In RFC-5085, section 5.3 VCCV capability advertisement for MPLS PWs, there is no clarity about the CC type usage per PW.
> So, can we have different CC type configurations per PW if the node supports more than one CC types?

	Yes, the idea is that the PW can be configured with any of the set of modes from 1...N, and then that set of "capabilities" is then narrowed down to a single one using the rules described in the RFC.

> Example:
> MPLS capable PW originating node supports all three CC types [1. ACH 2. Router alert label 3. TTL expiry] for OAM packets demultiplexing.
>  
> Can 3 PWs be setup with below configurations even though the PW originating node supports all CC types?
>  

	By "supported" types you should send configured types, and yes, you should send all of them. Using the largest set provides the most opportunity for configuration matches.  Although if you have two ends of the PW that you are configuring yourself and you know precisely which mode you want to use, just configure a single one so there is no guessing as to which mode will be used. 

	--Tom

> 
> 
> -- 
> Best Regards,
> Venkatesan Mahalingam.
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3

---

From: venkatesan mahalingam <[email-masked]>
Date: Mon, 12 Jul 2010 19:44:30 +0530

Hi Tom,
Thanks for your response. Your response triggered me to ask the below
questions,

1) If CC and CV types configuration is possible from the supported CC and CV
types per PW then why have we *not* taken care them in the pwTable
[RFC-5601] as configurable mib objects?
IANAPwCapabilities ::= TEXTUAL-CONVENTION
      STATUS      current
      DESCRIPTION
         "This TC describes a collection of capabilities related to
          a specific PW.
          Values may be added in the future based on new capabilities
          introduced in IETF documents.
         "
     SYNTAX   BITS {
       pwStatusIndication (0), -- Applicable only if maintenance
                               -- protocol is in use.
       *pwVCCV             (1)*
     }

PwEntry ::= SEQUENCE {
{
.............
..............
pwLocalCapabAdvert    IANAPwCapabilities,
.............
pwRemoteCapabilities  IANAPwCapabilities,
..............
pwOamEnable           TruthValue,
..............
}

2) Why do we need extra mib object "pwOamEnable" for enabling the OAM for PW
when we have capabilities objects of local (pwLocalCapabAdvert) and remote
(pwRemoteCapabilities) to identify the OAM enable/disable per PW?

If pwOamEnable  mib object is required, then please brief us at the time of
usage (OAM enable/disable).

Thanks,
Venkat.
On Mon, Jul 12, 2010 at 5:35 PM, Thomas Nadeau <[email-masked]>wrote:

>
>
> > Hi PWE3 group,
> >
> > In RFC-5085, section 5.3 VCCV capability advertisement for MPLS PWs,
> there is no clarity about the CC type usage per PW.
>        Yes, the idea is that the PW can be configured with any of the set
> of modes from 1...N, and then that set of "capabilities" is then narrowed
> down to a single one using the rules described in the RFC.
>
> > Example:
>        By "supported" types you should send configured types, and yes, you
> should send all of them. Using the largest set provides the most opportunity
> for configuration matches.  Although if you have two ends of the PW that you
> are configuring yourself and you know precisely which mode you want to use,
> just configure a single one so there is no guessing as to which mode will be
> used.
>
>        --Tom
>
> >
> >
> > --
> > Best Regards,
> > Venkatesan Mahalingam.

-- 
Best Regards,
Venkatesan Mahalingam.

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 12 Jul 2010 10:34:27 -0400

On Jul 12, 2010, at 10:14 AM, venkatesan mahalingam wrote:

> Hi Tom,
> Thanks for your response. Your response triggered me to ask the below questions,
>  
> 1) If CC and CV types configuration is possible from the supported CC and CV types per PW then why have we *not* taken care them in the pwTable [RFC-5601] as configurable mib objects?
>        pwVCCV             (1)

	The simple answer is that the MIBs were completed long before VCCV was.  We could augment (actually extend in MIB lingo) the capabilities in the pwTable by adding an OAM capability table as an extension that contains the VCCV configured options explicitly.

>  2) Why do we need extra mib object "pwOamEnable" for enabling the OAM for PW when we have capabilities objects of local (pwLocalCapabAdvert) and remote (pwRemoteCapabilities) to identify the OAM enable/disable per PW?
> If pwOamEnable  mib object is required, then please brief us at the time of usage (OAM enable/disable).

	Again, this was a broad stroke to enable/disable the VCCV capability at the time. As it was evolving, that was the level of granularity we all could agree on. 

	--Tom

>  
> Thanks,
> Venkat.
> On Mon, Jul 12, 2010 at 5:35 PM, Thomas Nadeau <[email-masked]> wrote:
> 
> 
> > Hi PWE3 group,
> >

---

From: venkatesan mahalingam <[email-masked]>
Date: Mon, 12 Jul 2010 21:06:52 +0530

Hi Tom,
  Thanks for your quick response and I've got some more below queries for
better understanding of PW OAM.

>> 2) Why do we need extra mib object "pwOamEnable" for enabling the OAM for
PW when we have capabilities objects of local (pwLocalCapabAdvert) and
remote (pwRemoteCapabilities) to identify the OAM enable/disable per PW?

>Again, this was a broad stroke to enable/disable the VCCV capability at the
time. As it was evolving, that was the level of granularity we all could
agree on.

1) Can we make the PW active if the pwLocalCapabAdvert value as *pwVCCV* and
pwOamEnable value as *false* assuming OAM will be enabled in the future
without re-signalling the PW?

2) What I infer from the pwOamEnable object's description is, this object
value can be set to true/false at any time even if the PW is active and PW
need not be re-signalled, is this understanding right?

3) IMO, PW CC/CV types need not be configured per PW locally, and all CC/CV
types supported by node can be negotiated with the peer, I don't see any
advantage by configuring the different CC/CV types i.e not all supported
CC/CV types per PW locally. So, could you please clarify the deployment
scenario where the CC/CV types configuration per PW would be most useful?

IMHO, local PW oam capabilities need *not* be configured per PW and can be
maintained at the node level for all PWs (useful only in the PW OAM packets
demultiplexing) and remote oam capability can be configured per PW.
Is this understanding right?

Thanks,
Venkat.
On Mon, Jul 12, 2010 at 8:04 PM, Thomas Nadeau <[email-masked]>wrote:

> 1) If CC and CV types configuration is possible from the supported CC and
> CV types per PW then why have we *not* taken care them in the pwTable
> The simple answer is that the MIBs were completed long before VCCV was.  We
> could augment (actually extend in MIB lingo) the capabilities in the pwTable
> by adding an OAM capability table as an extension that contains the VCCV
> configured options explicitly.
>
>   2) Why do we need extra mib object "pwOamEnable" for enabling the OAM
> for PW when we have capabilities objects of local (pwLocalCapabAdvert) and
> remote (pwRemoteCapabilities) to identify the OAM enable/disable per PW?
>
> Again, this was a broad stroke to enable/disable the VCCV capability at the
> time. As it was evolving, that was the level of granularity we all could
> agree on.
>
> --Tom
>
>
>
> Thanks,
> Venkat.

-- 
Best Regards,
Venkatesan Mahalingam.