Re: [Pals] draft-zzhang-intarea-generic-delivery-functions

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Yangfan,

Please see zzh> below.

-----Original Message-----
From: Yangfan (IP Standard) <[e-mail]>
Sent: Monday, January 18, 2021 5:24 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>; [e-mail]; mpls <[e-mail]>; [e-mail]
Cc: Kireeti Kompella <[e-mail]>; Ron Bonica <[e-mail]>
Subject: 答复: draft-zzhang-intarea-generic-delivery-functions

[External Email. Be cautious of content]


Hi authors,

The idea of a shim layer to provide the generic delivery function is interesting. I have 3 questions for clarification.

1. The draft request a new number of Internet Protocol Number registry for GDFH, I assume in this case, GDFH is used together with IP header. I wonder what the benefit is to have this generic header other than directly specifying the functionality as the next header?

Zzh> Allocating a number for GDFH from the IP number registry is not for putting a GDFH right after an IP header. The draft says:
      Next Header:  The type of next header.  For functions that IETF is
      concerned with, the "Next Header" values are from the "Internet
      Protocol Numbers" registry.  A next header could be another GDFH,
      so a value is to be assigned for GDFH from the registry.
Zzh> Consider the following situations when reading the above paragraph: 1) a GDFH is followed by a header that can currently follow an IP header 2) GDFH is followed by another GDFH. For 1), we want the "next header" field of the GDFH to be able to take existing IP protocol numbers (though some of them may not make sense with GDFH). For 2), we want the "next header" field of the first GDFH to be a value indicating that the next header is GDFH. When you combine 1) and 2), you can see that the value (identifying that next header is GBFH) needs to be from the IP protocol number registry.
Zzh> Additionally, imagine that a new delivery function is developed, and it can be done on top of IP and other layers. In that case, we do want to use a GDFH for that new function, and we do want to allow it after an IP header.

2. If the GDFH is used with MPLS, what is the difference compared to G-ACh?

Zzh> Let me read about G-ACh and get back.

3. If you suggest to use one uniform encapsulation in Figure 2 for IP/MPLS/BIER, starting with 0000 would make sense when it is encapsulated in MPLS, but seems unnecessary in IP. Because in IP, usually 5-tuple is used for hashing algorithm. First 4 zeroes don't help to avoid the hashing problem.

Zzh> Indeed starting with 0000 is for mpls case; but because GDFH is for "generic" purposes, that 0000 is always present.
Zzh> 0000 being different from 4 or 6, a router doing 5-tuple hashing should not mistake it as an IP packet (hence it would not do 5-tuple hashing).
Zzh> Thanks.
Zzh> Jeffrey

Best regards,
Fan


-----邮件原件-----
发件人: mpls [mailto:[e-mail]] 代表 Jeffrey (Zhaohui) Zhang
发送时间: 2021年1月12日 22:27
收件人: [e-mail]; mpls <[e-mail]>; [e-mail]
抄送: Kireeti Kompella <[e-mail]>; Ron Bonica <[e-mail]>
主题: [mpls] draft-zzhang-intarea-generic-delivery-functions

Hi,

I just posted https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-zzhang-intarea-generic-delivery-functions/__;!!NEt6yMaO-gk!QZhMuyy2Qh6dRiDc7sqPMUgVJFMu2oircI9Mi-4xslI9G4QzeqUM-qAkGDyyJMZk$ .

The initial version was posted to the tsvwg (https://urldefense.com/v3/__https://tools.ietf.org/html/draft-zzhang-tsvwg-generic-transport-functions-00__;!!NEt6yMaO-gk!QZhMuyy2Qh6dRiDc7sqPMUgVJFMu2oircI9Mi-4xslI9G4QzeqUM-qAkGErjaauy$ ). After discussions/feedback we are re-homing it to intarea wg. This new version also contains quite some changes based on the comments and feedback that we received (special thanks to Stewart).

Comments and suggestions are appreciated.

Thanks.
Jeffrey

Juniper Business Use Only

_______________________________________________
mpls mailing list
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!QZhMuyy2Qh6dRiDc7sqPMUgVJFMu2oircI9Mi-4xslI9G4QzeqUM-qAkGGaib2FE$

Juniper Business Use Only