Subject: [sfc] comments to draft-ietf-sfc-hierarchical-00

From: Linda Dunbar <[email-masked]>
Date: Wed, 17 Aug 2016 03:39:46 +0000

Authors of draft-ietf-sfc-hierarchical-00:

Here are my comments after reviewing the draft-ietf-sfc-hierarchical-00:

-         Section 2.2:

o   Is the "SFC-encapsulated" same as "NSH-encapsulated"?

o   If the packets entering the sub-domain are already "SFC-encapsulated", I assume that the packets exiting the sub-domain is also "SFC-encapsulated". Correct? Should add some references on the  actions done by the  "egress IBN" to restore it to the original SFC SHIM.

-        Section 3.1:

o   Does the phrase "after exiting a path in the sub-domain" mean packets leaving a sub-domain? If yes, what circumstance will cause "nesting NSH header" (does it mean adding a new NSH header)?

-        Section 3.1.1 (Page 8): Why "State cannot be created by packets arriving from lower-level chain?

o   There could be many types of "states" by SF. How can you generalize what packets can restore the " state"?

-        Section 3.1.4: what kind of use cases will trigger nesting NSH? The Figure 3 has 3 layers of NSH, greatly increase the likelihood of packet fragmentation. I am curious of what cases need multiple layers of NSH header. NSH is not same as MPLS label (which can be nested because of much smaller number of bytes) .

-

Cheers,

Linda Dunbar

---

From: <[email-masked]>
Date: Wed, 24 Aug 2016 09:39:32 +0000

Hi Linda,

Many thanks for the review.

Please see inline.

Cheers,
Med

De : Linda Dunbar [mailto:[email-masked]]
Envoyé : mercredi 17 août 2016 05:40
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]; [email-masked]
Objet : comments to draft-ietf-sfc-hierarchical-00

-           Section 2.2:

[Med] Yes.

o   If the packets entering the sub-domain are already "SFC-encapsulated", I assume that the packets exiting the sub-domain is also "SFC-encapsulated". Correct?

[Med] Yes. The text cites the following "The egress IBN finally restores packets to the original
   SFC shim and hands them off to SFFs.
"
Should add some references on the  actions done by the  "egress IBN" to restore it to the original SFC SHIM.
[Med] More details are introduced in Section 3.1 and subsections.

-          Section 3.1:

o   Does the phrase "after exiting a path in the sub-domain" mean packets leaving a sub-domain?
[Med] Yes. I do agree with you this sentence is to be clarified.

If yes, what circumstance will cause "nesting NSH header" (does it mean adding a new NSH header)?
[Med] adding another NSH header is one of the methods that are discussed in the document. Alternate options are also discussed.

-          Section 3.1.1 (Page 8): Why "State cannot be created by packets arriving from lower-level chain?
[Med] This is an assumption of the stateful model that assumes that a state must always be created by an incoming packet. I have some concerns with this text as it does not allow to send direct message from an SF. Also, it is not compatible with some SFs (e.g., MPTCP proxy). This is a pending point we are discussing among authors. FWIW, please check: https://github.com/dcdolson/draft-dolson-sfc-hierarchical/commit/a2cacebb021ba4e6a44af4d0f27ea7f002224c7e

o   There could be many types of "states" by SF. How can you generalize what packets can restore the " state"?
[Med] Can you please explicit this point? Thank you.

-          Section 3.1.4: what kind of use cases will trigger nesting NSH? The Figure 3 has 3 layers of NSH, greatly increase the likelihood of packet fragmentation. I am curious of what cases need multiple layers of NSH header.
[Med] We are not recommending NSH nesting, but are discussing how it can be used as a candidate option. Fragmentation can be indeed one of the drawbacks of this approach. This can be added to the draft.

NSH is not same as MPLS label (which can be nested because of much smaller number of bytes) .

-

Cheers,

Linda Dunbar

---

From: Dave Dolson <[email-masked]>
Date: Wed, 24 Aug 2016 13:34:10 +0000

Linda, thanks for reviewing.
See inline [DD]

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, August 24, 2016 5:40 AM
To: Linda Dunbar; [email-masked]; [email-masked]
Subject: RE: comments to draft-ietf-sfc-hierarchical-00

Hi Linda,

Please see inline.

Cheers,
Med

-           Section 2.2:

-          Section 3.1:

o   Does the phrase "after exiting a path in the sub-domain" mean packets leaving a sub-domain?
[Med] Yes. I do agree with you this sentence is to be clarified.
[DD] RFC7665 uses the language of "terminating SFPs". So how about, "At the termination of an SFP in the sub-domain, packets can be restored to an original upper-level SFP..."

-          Section 3.1.4: what kind of use cases will trigger nesting NSH? The Figure 3 has 3 layers of NSH, greatly increase the likelihood of packet fragmentation. I am curious of what cases need multiple layers of NSH header.
[Med] We are not recommending NSH nesting, but are discussing how it can be used as a candidate option. Fragmentation can be indeed one of the drawbacks of this approach. This can be added to the draft.
[DD] I've added, "By increasing packet overhead, nesting may lead to fragmentation or decreased MTU in some networks."

-

Cheers,

Linda Dunbar