Re: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

[Ron Parker <[e-mail]>]

Mohamed,

As a group, we’ve more or less accepted that the format of the MD-1 metadata is opaque and non-self describing.   For those that don’t like that, MD type 2 was the grand compromise.

Therefore, I wholeheartedly agree that imposing internal structure to MD-1 metadata is counter--productive.    There are 16 mandatory bytes whose use is described in other RFPs or not described at all.   Whether any particular usage imposes internal 4 byte boundaries or not is irrelevant since it is opaque, by definition.    Given the opaque and non-self-describing decisions, I strongly support modification of the NSH RFP to describe the MD-type 1 metadata as a single 16 byte opaque block of metadata instead of 4 4-byte context headers.

   Ron


From: sfc [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Friday, October 28, 2016 5:22 AM
To: Jim Guichard (jguichar) <[e-mail]>; Lucy yong <[e-mail]>; [e-mail]
Subject: Re: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

Hi Jim,

Please see inline.

Cheers,
Med

De : sfc [mailto:[e-mail]] De la part de Jim Guichard (jguichar)
Envoyé : vendredi 28 octobre 2016 02:01
À : Lucy yong; [e-mail]<mailto:[e-mail]>
Objet : Re: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

Hi Lucy,

The current context header structure has been documented for over 3 years without objection and has already completed WGLC.
[Med] I’m afraid things are more subtle, Jim. The point about the fuzzy design choice of 4 mandatory context headers was raised several times: e.g., https://trac.tools.ietf.org/wg/sfc/trac/ticket/19. I objected the ticket to be closed by the editors here: https://www.ietf.org/mail-archive/web/sfc/current/msg04434.html.

There doesn’t seem to be a technical distinction between the proposals, perhaps you could clarify your reasons for a change ?
[Med] The rationale is as follows:

·        Given that the semantic is defined elsewhere and no specific syntax validation are in the NSH spec, it does not make sense to impose the boundaries inside the 16 bytes block.

·        Defining the semantic of each 4-byte context header would be achieved by allowing to define the semantic of the 16bytes block as a whole.

·        The specification of the context header will be simplified.

o   Let’s consider the example in https://tools.ietf.org/html/draft-kumar-sfc-offloads-03:



       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |D| F |X|         Context Header 1                              |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |B|U|T|D|R|R|R|R| Context Header 2                              |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |                 Context Header 3                              |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |                 Context Header 4                              |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   X : Extend flags into first byte of "Context Header 2"

   B : Bidirectional Offload

   U : Unidirectional Offload

   T : TCP-control Exception Offload

   D : Drop Offload



   An X flag is defined because of these boundaries!! These same set of flags are aligned without any constraint for MD#2.



      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |B|U|T|D|S|V|R|R|R|R|R|R|         Offload-data                  |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



o   Let’s now consider the example in https://tools.ietf.org/html/draft-napper-sfc-nsh-broadband-allocation-01#section-4.1. With the 16bytes block, you don’t need to overload the reader with the CHi terminology:

OLD:
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | R | Sub | Tag |                 Context ID                    | CH1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Sub/Endpoint ID                         ~ CH2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                   Sub/Endpoint ID (cont.)                     | CH3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Service Information                        | CH4
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 3: NSH Context Allocation

NEW:


    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   | R | Sub | Tag |                 Context ID                    |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                       Sub/Endpoint ID                         |

   |                                                               |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                    Service Information                        |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                     Figure 3: NSH Context Allocation


·        In the absence of technical justification for the presence of the boundaries between 4byte headers, I suggest to go for a single 16bytes block.


Jim

From: Lucy yong <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, October 26, 2016 at 9:02 PM
To: Jim Guichard <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

Hi Jim,

There is no reason to specify 4x4 context headers if the NSH protocol only defines MD-1 as of a 16 bytes context header. This is the change we suggested.




OLD:



      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |Ver|O|C|R|R|R|R|R|R|   Length  |  MD type=0x1  | Next Protocol |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |          Service Path Identifer               | Service Index |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |                Mandatory Context Header                       |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |                Mandatory Context Header                       |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |                Mandatory Context Header                       |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |                Mandatory Context Header                       |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



NEW:

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |Ver|O|C|R|R|R|R|R|R|   Length  |  MD type=0x1  | Next Protocol |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |          Service Path Identifer               | Service Index |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |                Fixed Length Context Header                    |

     |                                                               |

     |                                                               |

     |                                                               |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Section 2 is introduction. Section 3 is the NSH protocol specification. Some normative statement should be stated in section 3.

Regards,
Lucy
From: Jim Guichard (jguichar) [mailto:[e-mail]]
Sent: Wednesday, October 26, 2016 5:45 PM
To: Lucy yong; [e-mail]<mailto:[e-mail]>
Subject: Re: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

Hi Lucy,

I am not following what you mean. The current NSH document specifies MD-type 1 with 4 x 4-byte context headers not a 16-byte context header. It further specifies that the semantics of the context headers is outside the scope of the document.

See section 2.3 bullet 3 which states “The semantics of the shared metadata is communicated via a control plane, which is outside the scope of this document, to participating nodes."

Jim

From: Lucy yong <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, October 26, 2016 at 6:00 PM
To: Jim Guichard <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

Hi Jim,

IMO: It is critical for the WG to make a consensus what to do with MD-1 before publishing this document: 1) NSH protocol specifies MD-1 with 16 bytes context header; 2) this specification specifies MD-1 with 16 bytes context header; the semantics of the context header will be specified in other document. The text we proposed (below) is applicable for 1). If we are open to 2), the text will be different. 2) is saying that the semantics of the context header will be specified later in another document. I don’t think we should open MD-1 for supporting both for sure. If we go with the 1), NSH header is proper text.

BTW: we also suggested to make a single 16 bytes as context header in the figure. I think that the word “mandatory” can be removed. This change applys to both 1) or 2).

This doc. specifies MD-2 as of the form of TLVs, which means that the NSH header conveys both the data semantics and data values. IMO: the doc. needs to specify the additional rules for TLVs and SFC-aware SP implementation. For examples, if an SF does not understand the MD class and/or type when MD-2 presents, what should it do?; if an SF does not find the metadata TLV it expects in the NSH header when MD-2 presents, what does it need to do?; Should the NSH require the individual TLVs to specify how SFs to handle the cases, or NSH can have a rule to apply to all TLVs (I doubt). IMO: this is also important for interworking.


Regards,
Lucy









From: sfc [mailto:[e-mail]] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, October 26, 2016 2:19 PM
To: [e-mail]<mailto:[e-mail]>
Subject: Re: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

Dear SFC WG:

One further point for discussion.

In the first sentence, would it not be more accurate to say “but the NSH base header does not convey that semantic…” rather than “but the NSH header does not convey that semantic in the context headers”.. The reason I ask this is two-fold; 1. The NSH base specification does not define the type-1 metadata but leaves it as opaque for specification elsewhere, and 2. The third sentence says "This specification does not make any assumption about the content placed in the mandatory context header”.

Jim

From: sfc <[e-mail]<mailto:[e-mail]>> on behalf of Jim Guichard <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, October 26, 2016 at 8:28 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [sfc] Proposed additional text for section 3.4 of draft-ietf-sfc-nsh-10

Dear SFC WG:

The following text has been proposed by Med and Lucy as an addition to section 3.4 of draft-ietf-sfc-nsh:

"This specification allows defining different semantics of metadata type 1 related mandatory context header, but the NSH header does not convey that semantic in the context headers. An SFC-aware SF MUST receive the data extraction schema first in order to get the data placed in the mandatory context header. How an SFC-aware SF gets the data extraction schema for the mandatory context header is outside the scope of this specification. This specification does not make any assumption about the content placed in the mandatory context header. Upon receiving an SFC packet with metadata type 1 present, if an SFC-aware SF is configured to use metadata but does not yet receive the data extraction schema for the mandatory context header, it MUST NOT process the packet and MUST log this error."

Before asking the editors of the document to make this change, I would like to hear opinions from other WG members so that consensus for this change may be reached. I would particularly like to hear opinions on the last sentence; specifically the ‘MUST NOT process’ as this implies that an SF must drop a packet if it is unable to process the metadata thereby breaking the chain. Do we need to be this strict or can we simply log an error and forward the packet through the chain?

Jim