Subject: Re: [mpls] mpls-rt review for draft-akiya-mpls-entropy-lsp-ping

From: "Daniel King" <[email-masked]>
Date: Mon, 20 Jan 2014 22:03:44 -0000

Hi All, 

As requested (MPLS RT), please find my brief review of
draft-akiya-mpls-entropy-lsp-ping.

The I-D updates LSP verification mechanism and Entropy Label LSPs. The I-D
is well written with a clear intention and should be polled for WG adoption.

A few suggested comments/updates/NITs:

- Abstract mentions RFC4379, but this I-D is updated by RFC6424?

- Although you expand acronyms in the "Abstract", you may want to expand
them again in the Introduction, and other parts of the document (ECMP, EL,
ELI, FAT, FEC, MS-PW, etc.).

- The last two sentences of the final paragraph from the "Introduction" is
slightly truncated. I would suggest the following updated text:

Section 3 of this document updates the procedures for multipath information
type {9} described in [RFC4379]. The rest of this document describes
extensions required to restore ECMP discovery and tracing capabilities for
the scenarios described. 
<<

- "Overview " section, second paragraph needs some minor grammar updates and
acronyms expanded. Suggest updating the text to:

LSP Ping initiating LSR sends MPLS echo request with multipath information.
This multipath information is described in Downstream Mapping TLV and
Downstream Detailed Mapping TLV (DSMAP/DMAP) echo request, and may contain a
set of IP addresses or set of labels.  Multipath information types {2, 4, 8}
carry a set of IP addresses and multipath information type {9} carries a set
of labels. Responder LSR (receiver of MPLS echo request) will determine the
subset of initiator specified multipath information which load balances to
each downstream (outgoing interface).  Responder LSR sends MPLS echo reply
with resulting multipath information per downstream (outgoing interface)
back to the initiating LSR.  Initiating LSR is then able to use specific IP
destination address or specific label to exercise specific ECMP path on the
responder LSR.
<<

- "Overview" section, third bullet. Suggest updating text to:

Initiating LSR sends existing multipath information to LSR which pushes
ELI/EL in label stack, but the initiating LSR can only continue to discover
and exercise specific path of ECMP, if the LSR which pushes ELI/EL responds
with both IP addresses and associated EL corresponding to each IP address.
<<

- "Multipath Type 9" section, uses "non-FAT pseudowire" terminology, then
later expands acronym to "Flow-Aware Transport Pseudowire", suggest
expanding acronym on first use. 

- "Multipath Type 9" section, fourth paragraph, the use of "must" looks like
it should "MUST". 

- "Initiating LSR Procedures" section, not really sure what a " IP based
load balancer" is?

- "FAT MS-PW Stitching LSR" section, suggest updating "xconnects" to
"cross-connects". 

- General observation for your figures, I would suggest you provide figure
numbers/titles.

Br, Dan. 

-----Original Message-----
From: Curtis Villamizar [mailto:[email-masked]] 
Sent: 17 January 2014 05:08
To: Loa Andersson
Cc: Sriganesh Kini; Xuxiaohu; Curtis Villamizar; Daniel King;
[email-masked]; [email-masked];
[email-masked]
Subject: Re: Correction: mpls-rt review for
draft-akiya-mpls-entropy-lsp-ping Was: Re: mpls-rt review of
draft-ietf-mpls-proxy-lsp-ping

In message <[email-masked]>
Loa Andersson writes:
 
> Folks,
>  
> This was the wrong document - I intended to have the review done for 
> draft-akiya-mpls-entropy-lsp-ping sorry for the confusion.
>  
> All other cordinates correct!
>  
> On 2014-01-03 14:44, Loa Andersson wrote:
> > Sri, Xiaohu, Curtis and Dan,
> >
> > You have been selected as MPLS Review team reviewers for 
> > draft-akiya-mpls-entropy-lsp-ping-01.
> >
> > Note to authors: You have been CC'd on this email so that you can 
> > know that this review is going on. However, please do not review 
> > your own document.
> >
> > Reviews should comment on whether the document is coherent, is it 
> > useful (ie, is it likely to be actually useful in operational 
> > networks), and is the document technically sound?  We are interested 
> > in knowing whether the document is ready to be considered for WG 
> > adoption (ie, it doesn't have to be perfect at this point, but 
> > should be a good start).
> >
> > Reviews should be sent to the document authors, WG co-chairs and WG 
> > secretary, and CC'd to the MPLS WG email list. If necessary, 
> > comments may be sent privately to only the WG chairs.
> >
> > Are you able to review this draft by January 20, 2014?
> >
> > Thanks, Loa
> > (as MPLS WG chair)
>  
> --
>  
>  
> Loa Andersson                        email: [email-masked]

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 22 Jan 2014 22:26:40 +0000

Hi Dan,

> Hi All,
> 
> As requested (MPLS RT), please find my brief review of draft-akiya-mpls-
> entropy-lsp-ping.
> 

Good question. Correct, portion of RFC4379 was updated by RFC6424.
1. RFC4379 is still the RFC which describes LSP ping/trace.
2. RFC4379 describes DSMAP.
3. RFC6424 updates RFC4379, introduced DDMAP which deprecated DSMAP.
4. DS Flags is a common field of DSMAP and DDMAP.
5. Multipath Information is a common field of DSMAP and DDMAP.
6. DSMAP is still widely used by many vendors.
7. This draft extends DS Flags, Multipath Information and procedures around them.
8. This draft introduces EL-FEC

So, (7) is technically an update to RFC6424 and (8) is an update to RFC4379. And because of (6), this document still refers to downstream as DSMAP/DDMAP.

> 
> - Although you expand acronyms in the "Abstract", you may want to
> expand them again in the Introduction, and other parts of the document
> (ECMP, EL, ELI, FAT, FEC, MS-PW, etc.).

Good point, will make this change.

> Section 3 of this document updates the procedures for multipath
> information type {9} described in [RFC4379]. The rest of this document
> describes extensions required to restore ECMP discovery and tracing
> capabilities for the scenarios described.
> <<

Oops, you are right, thanks.

> 
> - "Overview " section, second paragraph needs some minor grammar
> updates and acronyms expanded. Suggest updating the text to:
> 
> >>
> Downstream Detailed Mapping TLV (DSMAP/DMAP) echo request, and may
> contain a set of IP addresses or set of labels.  Multipath information types
> {2, 4, 8} carry a set of IP addresses and multipath information type {9}
> carries a set of labels. Responder LSR (receiver of MPLS echo request) will
> determine the subset of initiator specified multipath information which
> load balances to each downstream (outgoing interface).  Responder LSR
> sends MPLS echo reply with resulting multipath information per
> downstream (outgoing interface) back to the initiating LSR.  Initiating LSR is
> then able to use specific IP destination address or specific label to exercise
> specific ECMP path on the responder LSR.
> <<

ACK, thanks.

> ELI/EL in label stack, but the initiating LSR can only continue to discover and
> exercise specific path of ECMP, if the LSR which pushes ELI/EL responds with
> both IP addresses and associated EL corresponding to each IP address.
> <<

Ok.

> expanding acronym on first use.

ACK.

> - "Multipath Type 9" section, fourth paragraph, the use of "must" looks like

ACK.

> 
> - "Initiating LSR Procedures" section, not really sure what a " IP based load
> balancer" is?

This was pointed out by Curtis V. as well. I will add a terminology section.

> - "FAT MS-PW Stitching LSR" section, suggest updating "xconnects" to

ACK.

> - General observation for your figures, I would suggest you provide figure

ACK.

Thanks for details review!

-Nobo

> Cc: Sriganesh Kini; Xuxiaohu; Curtis Villamizar; Daniel King; mpls-
> [email-masked]; [email-masked];
> Subject: Re: Correction: mpls-rt review for draft-akiya-mpls-entropy-lsp-
> ping Was: Re: mpls-rt review of draft-ietf-mpls-proxy-lsp-ping
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls