Subject: [mpls-tp] Fwd: Question on use of MPLS vs MPLS-TP in draft-ietf-mpls-tp-cc-cv-rdi-01

From: Greg Mirsky <[email-masked]>
Date: Mon, 16 Aug 2010 13:28:32 -0700

Apologies for duplicates as I forgot to copy to the lists

Dear Authors, Editors and All,
I've noticed that sections 3.2 and 33. refer to MPLS CC and CV formats
whereas scope of the document is set to MPLS-TP networks only. Are these
references editorial omissions or intention is to define CC/CV/RDI formats
that are applicable to MPLS networks as superset of MPLS-TP without detailed
specification of behavior of Proactive CC/CV outside of MPLS-TP?

Regards,
Greg

---

From: Apratim Mukherjee <[email-masked]>
Date: Wed, 25 Aug 2010 05:08:06 -0700

Dear authors/editors , 

This draft contains essentially two parts:
1) First part deals with definitions of channel types for LSP Ping and BFD for MPLS-TP 
a) The BFD CV/CC channel types and GACh TLV requirements are already defined fully in draft-ietf-mpls-tp-cc-cv-rdi-01 and the definitions in this draft are really a re-definition for BFD CC/CV. In fact , this is more of a conflict since cc-cv-rdi defines two different channel types for CC/CV operations.

b) draft-ietf-mpls-tp-on-demand-cv-00 references draft-ietf-mpls-tp-lsp-ping-bfd-procedures-01 just to clarify on requirements for new LSP Ping channel type ( Section 1.3.) 
So , from perspective of definition of newly required channel types , 'LSP Ping / On-demand CV Channel Type' can be moved to draft-ietf-mpls-tp-on-demand-cv-xx. This looks reasonable since every OAM function ,such as lm/dm/fault/cc-cv-rdi defines the channel type and packet format including GACh TLV headers in its own drafts.

Is there any reason to specifically keep this in draft-ietf-mpls-tp-lsp-ping-bfd-procedures-01 draft?

2) Second part seems to be to define linkage between BFD and LSP Ping in MPLS-TP context :
a line in Section 3 :" ..When using BFD over MPLS-TP LSPs, the BFD  discriminator MUST either be signaled via LSP-Ping or be statically configured.."

However , this seems to be not in sync with section "3.5.7. Discriminator values"  of draft-ietf-mpls-tp-cc-cv-rdi-01 which states that "My Discriminator field MUST be set to a nonzero value (it can be a  fixed value), the transmitted your discriminator value MUST reflect back the received value of My discriminator field or be set to 0 if that value is not known." +"...the discriminator values have either local to the sink MEP or no significance (when not known)...."
 
This seems to indicate that sending Your Discriminator to 0 is valid. This looks fine from operational perspective since when we take into consideration that PHP is not supported in MPLS-TP, we always receive MPLS-TP BFD OAM packets with a valid label stack ( and a Source MEP for CV operation) and can associate that to a lsp/pw based on that. We don't need to have the Your Discriminator set to non-zero value in incoming BFD packet. This also removes the need for an extra set of initial lsp ping request / reply packets to bootstrap CC/CV operation if Remote Discriminator is not statically configured.

Hence , either cc-cv-rdi draft should be updated to specify that packets cannot be transmitted with 0 Your Disc OR this section should be also removed.

As a whole , do we need this draft at all or would it make sense to merge the appropriate portions to draft-ietf-mpls-tp-cc-cv-rdi-xx and draft-ietf-mpls-tp-on-demand-cv-yy ? 

Regards,
Apratim