Subject: [mpls] draft-zheng-mpls-lsp-ping-yang-cfg

From: "Nobo Akiya" <[email-masked]>
Date: Fri, 27 Mar 2015 11:01:03 -0500

Hi Authors,

I went through the document [briefly] and had some comments.

1. In resultInfo, it is critical that we include Return Code and Return
Subcode so that the users will know the nature of the error when problems
are encountered.

2. Similar to the first comment, it is also important to include the source
IP address of the received MPLS Echo Reply in the resultInfo, so that when a
non-success MPLS Echo Reply is received back by the initiating node, users
will know which network node sent that packet.

3. Frequency and ProbeCount is part of the Control Information, but the
mechanism also allows the Schedule Parameters to specify when to start/stop.
This will become ambiguous as the "operation" is done when MPLS Echo Request
is sent ProbeCount times at the Frequency specified but the endTest can also
defines the data/time when the operation should terminate. A clear
description of the relationship/rule of them will be helpful.

4. The Control Information allows specifying of an outgoing interface but
you'll also want to specify the nexthop address.

5. Being able to specify the TTL will be beneficial.

6. You'll also want to have some control over the ECMP, by being able to
specify the destination IP address (i.e., 127/8) or inclusion of ELI/EL and
the value of the EL. For the exact syntax, this is an aspect which will be
helpful to talk to multiple vendors. For example, I know of an
implementation which allows specifying of a _range_ of entropy set to be
used, so that a single Ping operation sweeps the entropy set. Whether such
capability is included in the yang definition or kept outside of it is a
good discussion to have.

7. Before going too far forward with just the Ping, it'll be good to add the
mechanism for Traceroute as well. Specifically how do we notify the
information in the received DSMAP/DDMAP (with various Sub-TLVs of the
DDMAP).

8. Related to comment 7, even the Ping operation may want to allow inclusion
of a DSMAP/DDMAP. This will be useful when used together with a specific TTL
value.
 
Thanks!

-Nobo

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 27 Mar 2015 17:03:23 +0000

Hi Nobo,
many thanks for thorough, don't be too modest with 'briefly', review and thoughtful comments. Some will be addressed in our presentation, as support of p2mp planned already and will come in upcoming version(s).

	Regards,
		Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Nobo Akiya
Sent: Friday, March 27, 2015 11:01 AM
To: [email-masked]
Cc: 'mpls'
Subject: [mpls] draft-zheng-mpls-lsp-ping-yang-cfg

Hi Authors,

1. In resultInfo, it is critical that we include Return Code and Return Subcode so that the users will know the nature of the error when problems are encountered.

2. Similar to the first comment, it is also important to include the source IP address of the received MPLS Echo Reply in the resultInfo, so that when a non-success MPLS Echo Reply is received back by the initiating node, users will know which network node sent that packet.

3. Frequency and ProbeCount is part of the Control Information, but the mechanism also allows the Schedule Parameters to specify when to start/stop.
This will become ambiguous as the "operation" is done when MPLS Echo Request is sent ProbeCount times at the Frequency specified but the endTest can also defines the data/time when the operation should terminate. A clear description of the relationship/rule of them will be helpful.

4. The Control Information allows specifying of an outgoing interface but you'll also want to specify the nexthop address.

6. You'll also want to have some control over the ECMP, by being able to specify the destination IP address (i.e., 127/8) or inclusion of ELI/EL and the value of the EL. For the exact syntax, this is an aspect which will be helpful to talk to multiple vendors. For example, I know of an implementation which allows specifying of a _range_ of entropy set to be used, so that a single Ping operation sweeps the entropy set. Whether such capability is included in the yang definition or kept outside of it is a good discussion to have.

7. Before going too far forward with just the Ping, it'll be good to add the mechanism for Traceroute as well. Specifically how do we notify the information in the received DSMAP/DDMAP (with various Sub-TLVs of the DDMAP).

8. Related to comment 7, even the Ping operation may want to allow inclusion of a DSMAP/DDMAP. This will be useful when used together with a specific TTL value.
 
Thanks!

-Nobo

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls