Re: [mpls] MPLS-RT review of draft-cheng-mpls-inband-pm-encapsulation-04

[Weiqiang Cheng <[e-mail]>]

Hi Chandra,

 

Many thanks for your thorough review and insightful comments.

We've discussed them, please see inline our responses tagged with
<Weiqiang>.

 

Best Regards,

Weiqiang (on behalf of co-authors)

 

发件人: mpls [mailto:[e-mail]] 代表 Chandrasekar Ramachandran
发送时间: 2020年12月14日 04:38
收件人: [e-mail]; mpls-chairs@ietf.
org; Mach Chen; [e-mail]
主题: [mpls] MPLS-RT review of draft-cheng-mpls-inband-pm-encapsulation-04

 

I have reviewed draft-cheng-mpls-inband-pm-encapsulation-04 and do not have
any technical concern or comment so far on the procedures defined in the
draft. I have a couple of editorial comments and a few questions for the
authors. Some of the questions could be clarified over mail whereas the rest
may require some clarifying text in the draft.

 

(1) The paragraph in Section 1 comparing the proposal in this draft with SFL
and IOAM could be expanded providing more clarity. Specifically, it has been
stated that this draft is complimentary to both SFL and IOAM. Is it the
intention of the authors to convey that different sets of flows may use
different methods?

<Weiqiang> Different sets of flows may use different methods, otherwise, the
same set of flows may also use different methods simultaneously, e.g., one
flow may use the method proposed in this draft to achieve performance
measurement, at the same time, use the IOAM method to achieve telemetry info
collection.

 

(2) Could you point to the draft or RFC that defines overloading of the TC's
highest order two bits for alternative marking? I couldn't find the relevant
section in RFC 8321.

<Weiqiang> No, it's defined in this document but not reference to other
document. We noticed that RFC 3032 defines the three-bit field as "EXP"
field, and then RFC 3270 proposes that DSCPs may be encoded in the EXP
field, and then RFC 5129 defines how an operator might define some of the
EXP codepoints for ECN, and then RFC 5462 renames "EXP" field to "Traffic
Class" field, and both RFC 3270 and RFC 5129 are not obsoleted by RFC 5462,
could we say that RFC 3270 and RFC 5129 define overloading of TC bits?

 

(2) It seems "MPLS VPN" has been used to indicate any kind of service like
PW, EVPN etc. If there is a more appropriate terminology instead of VPN,
then that could be used in the draft. Similarly, I suppose the term "MPLS
LSP" has been used to indicate any kind of transport LSP and the same
comment will apply for that too.

<Weiqiang> ACK. We'll try to find more appropriate terms for "MPLS VPN" and
"MPLS LSP". Any suggestions from you or others are welcome.

 

(3) What does the text "Flow-ID is applied to MPLS LSP and MPLS VPN
synchronously" in Section 2 mean? The text in Section 2.1 states that if
there are multiple flow-id labels, then each of them must be different.
Could you explain one example application of two flow-id labels - one below
transport label and the other below the service label?

<Weiqiang> Figure 4 gives an example on what the text you quoted in Section
2 means. One example application of two flow-id labels - one below transport
label and the other below the service label is hierarchical VPN.

 

(3) This is in continuation from the previous question. If one wants to
count the same flow as it traversers across transport & service layers, then
the NMS or the flow-id allocations has to allocate two flow-id values for
the same flow and impose the two flow-id labels at the appropriate locations
on the label stack. Is that correct?

<Weiqiang> Yes, that's correct.

 

(5) Section 4 only provides flow-id allocation for IP flows identified by IP
five tuples & IP DHCP. But, does the mechanism defined in this draft
preclude the allocation & use of flow-id labels for SR policies? For
example, the notion of an SR (transport) policy is transparent to the
transit nodes that only forward based on the top label on the label stack.
Is the alternative marking method defined in this draft applicable to such
SR (transport) policies also?

<Weiqiang> Thanks for pointing that out and the good question. We think the
alternate marking method defined in this draft is also applicable to SR
policy.

 

(6) Section 5 only introduces the FRLD as a parameter analogous to ERLD for
entropy labels without any associated procedures for a node to define and
advertise its FRLD. Is there any companion draft to define the procedures
for FRLD or do you plan to write one?

<Weiqiang> Actually the companion draft has already been there, and we plan
to submit that draft once this draft is adopted as WG draft. That draft is
analogous to the combination of draft-ietf-isis-mpls-elc and
draft-ietf-ospf-mpls-elc.

 

Thanks,

Chandra.


Juniper Business Use Only