Subject: Re: [sfc] questions on draft-quinn-sfc-nsh-03

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 6 Nov 2014 23:20:36 +0000

David,

Some responses Inline.

From: Dave Dolson <[email-masked]<mailto:[email-masked]>>
Date: Friday, October 31, 2014 9:54 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [sfc] questions on draft-quinn-sfc-nsh-03

After reading draft-quinn-sfc-nsh-03, I have some questions and comments:

The optional TLV format:
- the TLV length should by in bytes (vs. words), allowing strings that aren't a multiple of 4 bytes, with padding to 4-byte alignment. This is the Diameter approach, for example. (RFC6733)
- Encoding "critical" in upper bit of Type is confusing. Why not use one of the reserved flags in the header? Or make type 7 bit field?
SK> It can effectively be processed as a 7-bit field if you treat the 7th as another flag but it also provides the flexibility of categorizing certain types as critical by definition.
- the wording about critical should be clarified. “Receiver” devices MUST drop and “transit” devices MUST NOT drop; neither “receiver” nor “transit” is clearly defined. I think you intend that the critical types must be understood by the end-point (e.g., the protocol end-point addressed by the GRE packet).

The definition of service index action is not precise. It says that if it is zero, the packet is to be dropped,  but I could not understand if that means if received with a zero or if received with "1" and decremented to zero?
Instead, I claim that a packet received with a service index of zero is actually a valid packet if this is the end of the chain and the packet is de-encapsulated.
It would be a configuration error for there to be a forwarding entry that has another hop in the chain for service index zero.
(My understanding is that an NSH forwarding table is indexed by at least {path_id, service_index}, pointing to a record that indicates either next hop in the chain or end of chain.)
Of course, lack of an entry in NSH forwarding table would also cause the packet to be dropped.
SK> Received with zero or one is an error and must be dropped. Here is a pseudo code of how I would use it :
-- SFF receive path processing for NSH encapsulated pkt --
If (NSH.si <= 1) {
  Drop & follow error path
}

NSH.si--

if (NSH.si == 1) {
    Strip NSH
    Hand the pkt to the network-forwarder
} else {
    Determine SFP next-hop
    Continue on SFP if no error
}
--

I feel that it is not necessary to fix the number of mandatory headers at 4. The number of headers could be subject to the scheme of the MD type, allowing optimization to different use cases. Maybe 2 or 5 are useful in different cases.

There is no discussion of fragmentation or prohibition thereof.
SK> Arch document has a section on fragmentation. This being an encapsulation, a reference or some discussion of it is a good idea.

Surendra.

Thanks,
David Dolson
Senior Software Architect
Sandvine

---

From: Dave Dolson <[email-masked]>
Date: Tue, 11 Nov 2014 02:32:04 +0000

I made this comment:
"I feel that it is not necessary to fix the number of mandatory headers at 4. The number of headers could be subject to the scheme of the MD type, allowing optimization to different use cases. Maybe 2 or 5 are useful in different cases.

Are you willing to changing the spec to accommodate this? I would also add an MD type to mean "no fixed metadata"

From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Thursday, November 06, 2014 1:21 PM
To: Dave Dolson; [email-masked]
Subject: Re: [sfc] questions on draft-quinn-sfc-nsh-03

David,

Some responses Inline.

The optional TLV format:
- the TLV length should by in bytes (vs. words), allowing strings that aren't a multiple of 4 bytes, with padding to 4-byte alignment. This is the Diameter approach, for example. (RFC6733)
- Encoding "critical" in upper bit of Type is confusing. Why not use one of the reserved flags in the header? Or make type 7 bit field?
SK> It can effectively be processed as a 7-bit field if you treat the 7th as another flag but it also provides the flexibility of categorizing certain types as critical by definition.
- the wording about critical should be clarified. "Receiver" devices MUST drop and "transit" devices MUST NOT drop; neither "receiver" nor "transit" is clearly defined. I think you intend that the critical types must be understood by the end-point (e.g., the protocol end-point addressed by the GRE packet).

NSH.si--

if (NSH.si == 1) {
    Strip NSH

Surendra.

Thanks,
David Dolson

---

From: "Dolganow, Andrew (Andrew)" <[email-masked]>
Date: Tue, 11 Nov 2014 03:37:54 +0000

Just to again reiterate the number of mandatory headers.

I and Dave are ok with using MD type to encode that. This MD 1 would carry only base and service path header. The header should also allow inclusion of optional headers.

Andrew

Sent from my iPhone

On Nov 10, 2014, at 4:32 PM, Dave Dolson <[email-masked]<mailto:[email-masked]>> wrote:

I made this comment:
“I feel that it is not necessary to fix the number of mandatory headers at 4. The number of headers could be subject to the scheme of the MD type, allowing optimization to different use cases. Maybe 2 or 5 are useful in different cases.

Are you willing to changing the spec to accommodate this? I would also add an MD type to mean “no fixed metadata”

From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Thursday, November 06, 2014 1:21 PM
To: Dave Dolson; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] questions on draft-quinn-sfc-nsh-03

David,

Some responses Inline.

The optional TLV format:

If (NSH.si<http://NSH.si> <= 1) {
  Drop & follow error path
}

NSH.si<http://NSH.si>--

if (NSH.si<http://NSH.si> == 1) {
    Strip NSH
    Hand the pkt to the network-forwarder
} else {
    Determine SFP next-hop
    Continue on SFP if no error
}
--

Surendra.

Thanks,
David Dolson

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc