Subject: [mpls] MPLS-RT review on draft-farrelll-mpls-opportunistic-encrypt-04.txt

From: Mach Chen <[email-masked]>
Date: Fri, 15 May 2015 08:49:00 +0000

Hi All,

I reviewed draft-farrelll-mpls-opportunistic-encrypt-04.txt as the member of MPLS Review Team and have the following comments:

is the document coherent?

Yes. 

is it useful (ie, is it likely to be actually useful in operational networks)?

Yes. 

is the document technically sound? 
Yes.

is the document ready to be considered for WG adoption?
Yes. 

BTW, after reading the document, I have the following comments:

1.
Section 1.1
"...Consideration of the impact of MPLS OS
   on MPLS Operations, Administration, and Management (OAM) and other
   MPLS management techniques also needs further exploration."

OAM is a critical tool for MPLS network, some OAM functions (e.g., LSP Ping, traceroute) that depend on special label (Router Alter label, GAL) and TTL may not work due to the encryption. Especially the hop-by-hop encrypted scenario. 

In addition, seems that the following description conflicts with some existing definitions.
For example:
Section 3, the 3rd para:
"The MEL MUST have the bottom of stack bit (the S bit) set and MUST be
   followed by a pseudowire control word [RFC4385].  The format of the
   control word is described in Section 3.2."

But RFC5586 says GAL must be at the bottom of the stack. And for PW, the fat PW also requires to be put at the bottom of the stack.

2. 
Section 3.1
"TC:    SHOULD be copied from the TC of the first encrypted label."
Seems it implies that there MUST be label(s) encrypted, does it and why? 
Are there scenarios that only the MPLS payload encrypted and the label stack is left as cleartext? I personally think there should be. And if so, what the value of TC should it be? There will be no "first encrypted label" then. 

3.
Section 3.1
"TTL:   SHOULD be set to zero to prevent encrypted packets being
          accidentally forwarded beyond the point of intended
          decryption.

Shouldn't the TTL be set to 1 instead? In my understanding, when received packets with TTL=0, the packets will be dropped. 

And when do traceroute, the TTL should be set to corresponding value for different hops. 

4.
Section 4.2.3
Regarding the Key Exchange Message TLV, where the Path Identifier(24-bit) and LSP-ID(32-bit) are designed to carry the LSP-ID, why do they have different length?

Seems that only RSVP-TE based and MPLS-TP LSPs have LSP-ID and the length is 16 bit, so what's the LSP-ID for other LSPs ? For example LDP, BGP based, PW etc., where LSPs are normally expressed by FECs. IMHO, you may need more flexible way to identify and LSP. 

5.

Do you consider the MPLS-in-GRE/UDP scenarios? And how does MPLS OS apply to those cases?

Best regards,
Mach