Subject: [mpls] Comments on draft-nitinb-lsp-ping-over-mpls-tunnel-01

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 03 Apr 2008 11:22:47 +0100

Some comments of draft-nitinb-lsp-ping-over-mpls-tunnel-01

General:

Section 3.2.3:

Operation Type
"A FEC Swap operation is to be simulated by including a POP type FEC change
sub-TLV followed by a PUSH type FEC change sub-TLV."

During the ITU-T SG15 ad hoc meeting on T-MPLS in February, the ITU model
(G.8110) of MPLS was discussed.  G.8110 models a SWAP as a POP followed by a
PUSH and at least one of the IETF representatives at the meeting expressed
the view that modelling a SWAP as a POP followed by a PUSH did not
sufficiently describe the behaviour as per the MPLS architecture (RFC3031).

You appear to be doing the same here, so is modelling a SWAP as a POP
followed by a PUSH sufficient in this context?

Remote peer address
"If the operation type is POP, the remote peer address MAY not be set to
Unspecified."

I find the use of the term "MAY not" confusing.  If you really mean MAY then
as it is optional, IMO the not is superfluous.

Editorial:
Section 1
S/using which/by which/

Section 3.1
S/tlv/TLV/

Section 3.2
S/sub-tlv/sub-TLV/

Section 3.3
S/deprecatd/deprecated/
S/tlv/TLV/

Section 4.1.1
S/when that the/when the/

Section 4.1.2
S/one for the PUSH operation/one with a PUSH operation/
S/FEC-tlv/FEC TLV/
S/Push/PUSH/

Section 4.3
S/In cases where the a detailed/In cases where a detailed/
S/tlv/TLV/

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

---

From: "Nitin Bahadur" <[email-masked]>
Date: Fri, 4 Apr 2008 17:31:18 -0700

Hi Ben,

> (G.8110) of MPLS was discussed.  G.8110 models a SWAP as a POP
followed by
> a

Very good observation. In the forwarding plane, a POP/PUSH does not tell
you much. In the control plane, a POP/PUSH can be tailored to provide
sufficient detail so that the semantics are much clear. In this draft,
the POP/PUSH operations have FEC and peer-address associated with them.
That should help clarify the intended behavior. If there is still a
chance of ambiguity, we can modify the control information for clarity.

> I find the use of the term "MAY not" confusing.  If you really mean
MAY
> then

Yes, that's correct. The intention is "MAY" and not "MAY not". I shall
have that corrected.

I've taken care of the editorials. Thanks for combing through the
document in detail.

Nitin